Clone wiki

SCons / BugParty / IrcLog2010-07-06

The SCons wiki has moved to

16:49:42  *      Garyo (~[]( has joined #SCONS 
16:49:43  *      jason_at_intel_ (~[]( has joined #SCONS 
16:55:13  *      sgk_ (~[]( has joined #SCONS 
16:56:18  *      sgk_ is now known as sgk 
17:05:20  *      [GregNoel](GregNoel) has arrived... 
17:06:51  <[GregNoel](GregNoel)>     Lots to do today; shall we start? 
17:06:59  <Garyo>        I'm ready 
17:07:02  <sgk>  let's go 
17:07:05  <jason_at_intel_>      ready 
17:07:04  <[GregNoel](GregNoel)>     2443 closed by Steven 
17:07:04  <[GregNoel](GregNoel)>     2570 consensus 2.1 p1 Gary 
17:07:04  <[GregNoel](GregNoel)>     2551 consensus 2.1 p4 Steven 
17:07:04  <[GregNoel](GregNoel)>     That clears off the 1.3 issues 
17:07:04  <[GregNoel](GregNoel)>     2549 does Russel have commit? 
17:07:46  <Garyo>        2549: not that I've seen 
17:07:57  <sgk>  i don't believe he does 
17:08:11  <[GregNoel](GregNoel)>     so someone will have to proxy it for him 
17:08:44  <sgk>  i can do the integration 
17:09:03  <Garyo>        thanks, sounds good 
17:09:36  <[GregNoel](GregNoel)>     done 
17:09:40  <[GregNoel](GregNoel)>     2560 consensus anytime p1 Greg 
17:09:40  <[GregNoel](GregNoel)>     2564 consensus Gary+Greg this summer 
17:09:40  <[GregNoel](GregNoel)>     2636 If Russel doesn't want it, I can go with future p3. 
17:09:40  <sgk>  do we want a new issue to track the idea of a [WhereIs](WhereIs)() for LIBPATH ? 
17:09:51  <[GregNoel](GregNoel)>     Yes, I'll create it. 
17:09:55  <sgk>  thnx 
17:10:03  <Garyo>        2564: will have to be August for me, ok Greg? 
17:10:40  <[GregNoel](GregNoel)>     Garyo, late August is fine; first week is family holiday 
17:10:57  <Garyo>        ok.  Shouldn't be all that painful I think. 
17:11:25  <[GregNoel](GregNoel)>     2637 fixed by Greg 
17:11:25  <[GregNoel](GregNoel)>     2638 consensus anytime p2 Greg 
17:11:25  <[GregNoel](GregNoel)>     2648 I suppose research is OK, but there are starting to be too many research issues that aren't getting processed (and that includes me). 
17:12:02  <Garyo>        me too 
17:12:06  <sgk>  me three 
17:12:34  <sgk>  hmm... 
17:12:52  <sgk>  would it help or hurt if we also put the research issues on the list to review every bug party ? 
17:12:54  <sgk>  status update, etc. 
17:12:59  <jason_at_intel_>      Don't know enough ... 
17:13:05  <sgk>  might provide additional incentive to look at them instead of letting them languish 
17:13:06  <Garyo>        Eek, then we'd have to *do* them! :-) 
17:13:10  <sgk>  if only to get them off the list 
17:13:16  <sgk>  :-) 
17:13:30  <[GregNoel](GregNoel)>     sgk, not a bad idea; we certainly need some concept of a time limit. 
17:13:51  <Garyo>        Greg: time limit ++ 
17:13:58  <sgk>  agreed 
17:14:25  <jason_at_intel_>      +1 
17:14:25  <Garyo>        So... sgk, still want to take this one as research? 
17:14:37  <sgk>  2648? yes 
17:14:39  <[GregNoel](GregNoel)>     Maybe p1 issues are reviewed, and each party increases the priority of non-p1 issues? 
17:15:00  <Garyo>        Greg: I was almost going to propose that but didn't want to make more work. 
17:15:06  <Garyo>        But I like it. 
17:15:25  <[GregNoel](GregNoel)>     Yeah, it'd be a hassle, but it might be worth it 
17:16:05  <Garyo>        If you don't mind I think it's a great way to go.  RT (our bug tracker at work) does that automatically each night. 
17:15:19  <sgk>  of research issues, yes? 
17:15:23  <sgk>  not all issues 
17:15:41  <[GregNoel](GregNoel)>     sgk, yes, only research issues. 
17:15:59  <sgk>  if it can be done without too much extra hassle, it sounds worthwhile 
17:16:02  <[GregNoel](GregNoel)>     So, 2648, what priority? 
17:16:28  <Garyo>        p3 or p4, since it's user error anyway 
17:16:47  <[GregNoel](GregNoel)>     either works for me 
17:16:45  <sgk>  since i'm on hook, p4 
17:16:53  <[GregNoel](GregNoel)>     p4, done 
17:16:55  <sgk>  that'll give me three bug partys before we review it again... :-) 
17:17:21  <[GregNoel](GregNoel)>     2649 Steven just updated it and I haven't had time to look at it.  Are there other opinions? 
17:17:29  <Garyo>        Let's make an effort to get the existing research issues cleared up before we go and prioritize all of them 
17:17:49  <sgk>  Garyo++ 
17:19:01  <[GregNoel](GregNoel)>     Was that about 2649 or still on the research issues? 
17:19:07  <Garyo>        2649: sounds like greg & sk are figuring out if it's an issue or not, right? 
17:19:20  <jason_at_intel_>      it seems like this need to be looked into more 
17:19:26  <[GregNoel](GregNoel)>     yes, but what to do with it? 
17:19:35  <sgk>  Jason_at_intel:  well, that's kind of what we're doing with it... :-) 
17:19:43  <[GregNoel](GregNoel)>     review next time? 
17:19:45  <jason_at_intel_>      All i know is that Aliases and Depends don't work together and i would like them to myself 
17:20:03  <jason_at_intel_>      :-) 
17:20:19  <Garyo>        Jason: but look at this issue.  Steven thinks there's nothing wrong with Alias once 2443 is fixed. 
17:20:39  <sgk>  well, more "hoping" than "thinking," but yes in principal... :-) 
17:21:03  <sgk>  Jason_at_intel:  we need an actual test case 
17:21:11  <sgk>  i'm too close to the code to create one 
17:21:12  <jason_at_intel_>      right.. so do we want to link these items? 
17:21:22  <Garyo>        Your dep graph is pretty clear there.  (Maybe we should tag Alias nodes visibly in dep graphs??) 
17:21:49  <sgk>  Garyo:  yeah, we should probably have a Python-like <Alias 'sub1/a.lib'> or some such 
17:21:58  <sgk>  or at least a mode that displays stuff like that 
17:22:20  <sgk>  well, the items aren't linked per se 
17:22:26  <Garyo>        I'd like that, for clarity.  I'd be happy with (Alias) after the name. 
17:22:46  <sgk>  the fix for the previous issue of using Depends() without Builders is already committed 
17:22:41  <[GregNoel](GregNoel)>     The curve here is that Alias() can supposedly have an action. 
17:23:09  <Garyo>        Greg: you're right, I'm just sidetracking. 
17:23:12  <sgk>  this is about trying to make sure, while our attention is here, that we get similar problems in other areas (if they exist) 
17:23:26  <[GregNoel](GregNoel)>     point. 
17:24:26  <sgk>  The fix I submitted for no-Builder Depends() isn't specific to any node type 
17:24:28  <[GregNoel](GregNoel)>     My attempts to use Alias() with an action have been hit-and-miss; sometimes they work, sometimes they don't, and I don't see a pattern. 
17:24:47  <sgk>  so there's a decent chance that it makes the Alias() case better, at least 
17:25:03  <jason_at_intel_>      it seems that a test case should not be to hard for this one 
17:25:30  <sgk>  cool, if you can come up with one, that would be great 
17:25:49  <Garyo>        OK, how about we close this one next time if no test case shows up? 
17:26:01  <[GregNoel](GregNoel)>     I think time is up on this issue; review next time? 
17:26:17  <[GregNoel](GregNoel)>     Or close it... {;-} 
17:26:01  <sgk>  that sounds good 
17:26:21  <jason_at_intel_>      is it correct to say this bug is related to stuff like : 
17:26:22  <jason_at_intel_>      x=env.Alias("foo",action) 
17:26:23  <jason_at_intel_>      env.Depends(env.Alias(boo,x)) 
17:26:51  <Garyo>        huh? 
17:27:06  <jason_at_intel_>      last line should be env.Depends(env.Alias(boo),x) 
17:27:20  <Garyo>        What's boo? 
17:27:31  <jason_at_intel_>      you can't maps depends to to alias 
17:27:32  <jason_at_intel_>      "boo" 
17:27:39  <jason_at_intel_>      just an alias name 
17:27:59  <jason_at_intel_>      foo has an actions.. so i can say Scons foo 
17:28:04  <Garyo>        so the Alias "boo" depends on the Alias "foo" which has an action? 
17:28:08  <jason_at_intel_>      but i can say't scons boo 
17:28:16  <sgk>  jason_at_intel:  if that's a use case that fails, sure 
17:28:37  <jason_at_intel_>      but why? 
17:28:40  <Garyo>        jason: if it really fails, put it in this bug. (imho) 
17:28:50  <jason_at_intel_>      Sure. 
17:28:52  <sgk>  the problem is that on our own we're not successfully characterizing what exactly "this bug" is... :-) 
17:29:07  <Garyo>        #2649 
17:29:12  <[GregNoel](GregNoel)>     2650 I'm also interested in this issue, so it could go on my plate instead. 
17:29:53  <Garyo>        2650: if this works it could be a huge enhancement! 
17:30:04  <sgk>  [GregNoel](GregNoel):  if you want 2650, that'd be great 
17:30:05  <jason_at_intel_>      +1 for 2650 
17:30:41  *      sgk changes the relevant cell in the spreadsheet... 
17:30:20  <Garyo>        I don't care if you make a SEP for it really. 
17:30:47  <[GregNoel](GregNoel)>     Well, I'm beginning to agree with you after the discussion with Russel. 
17:31:22  <Garyo>        I found the SEP thing really useful when doing the site_scons dirs. 
17:31:17  <jason_at_intel_>      :-) 
17:31:23  <jason_at_intel_>      like the additions 
17:31:51  <[GregNoel](GregNoel)>     OK, draft a SEP, review next time? 
17:31:57  <Garyo>        great 
17:32:00  <sgk>  sounds good 
17:32:12  <[GregNoel](GregNoel)>     done 
17:32:15  <[GregNoel](GregNoel)>     2651 
17:33:08  <Garyo>        I could probably look at this for 2.2 
17:33:13  <Garyo>        or 2.3 
17:33:27  <Garyo>        but not 2.1 
17:33:55  <Garyo>        I have plenty of rpm-based machines around 
17:34:05  <Garyo>        2.3 p4 garyo 
17:34:11  <sgk>  works for me 
17:34:13  <[GregNoel](GregNoel)>     works for me 
17:34:31  <[GregNoel](GregNoel)>     (jinx) 
17:34:20  <[GregNoel](GregNoel)>     2652 Gary can have it, but what priority? 
17:34:55  <jason_at_intel_>      does this have to be loaded in the default builder to work? 
17:35:03  <sgk>  p3 
17:35:05  <Garyo>        I have a bunch of other things, p3 is good for me 
17:35:14  <Garyo>        Jason: ? 
17:35:28  <[GregNoel](GregNoel)>     p3 works for me; done 
17:35:45  <[GregNoel](GregNoel)>     2653 
17:35:50  <sgk>  jason_at_intel:  "does this have to be loaded..."  "this" == ? 
17:35:56  <Garyo>        2653: how do you make a symlink on windows like that? 
17:36:04  <sgk>  he doesn't make it on Windows 
17:36:09  <sgk>  it's an NFS-mounted file system 
17:36:18  <sgk>  so it was made on Linux/BSD/what have you 
17:36:21  <jason_at_intel_>      I thought copyAs was a tool that has to be loaded to so it can be called 
17:36:24  <Garyo>        omg 
17:36:31  <jason_at_intel_>      that is why i am making a CCopy builder in Parts 
17:36:36  <sgk>  but it makes SCons gag, and we should at least be more graceful than a stack trace 
17:37:03  <jason_at_intel_>      so the gag might be python itself 
17:37:19  <jason_at_intel_>      windows has some rules about how files should be open 
17:37:28  <sgk>  give 2653 to me, my systems at work are set up so I can test this 
17:37:32  <[GregNoel](GregNoel)>     I'm lost; what are we talking about? 
17:37:40  <jason_at_intel_>      and the standard way python does it violate the rules 
17:37:50  <Garyo>        I'm talking about 2563 
17:37:50  <sgk>  2653 
17:37:55  <jason_at_intel_>      2653? 
17:38:11  <Garyo>        sorry 2653 
17:38:37  <jason_at_intel_>      Anyways.. I been working on work around to the issue in Parts 
17:38:42  <[GregNoel](GregNoel)>     OK, then why does [CopyAs](CopyAs)() have to be loaded in 2653? 
17:39:11  <jason_at_intel_>      that was a different issue :-) 
17:39:28  <jason_at_intel_>      I thought copyAs was a tool that was not loaded by default 
17:39:32  <jason_at_intel_>      so the user could not call it 
17:39:49  <jason_at_intel_>      but i could be wrong 
17:39:46  <[GregNoel](GregNoel)>     What does that have to do with documenting it? 
17:40:10  <Garyo>        Re: 2653, Justin has just replied w/ how he makes these symlinks (mklink /d). 
17:40:16  <sgk>  [GregNoel](GregNoel):  nothing directly, talk of documenting [CopyTo](CopyTo)()[/CopyAs](BugParty/IrcLog2010-07-06/CopyAs)() prompted jason_at_intel to wonder about needing to load it 
17:40:31  <jason_at_intel_>      that it would need to be documented to for a manual load.. or we would want to have it load by default 
17:40:47  <sgk>  Garyo:  understood that more modern Windows file systems can make symlink-like things 
17:41:03  <sgk>  I'll try to look at that behavior, too 
17:41:21  <jason_at_intel_>      so on windows.. with 2653... you all know who to make symlinks and hardlinks 
17:42:22  <Garyo>        Jason: I see your point re: [CopyTo/CopyAs](CopyTo/CopyAs).  I'll note that in the doc.  However: shouldn't they just be loaded standard like Copy? 
17:42:39  <Garyo>        Why aren't they? 
17:42:41  <sgk>  it looks to me like [CopyTo](CopyTo)() / [CopyAs](CopyAs)() are loaded by default 
17:42:47  <sgk>  they're in Tool/ 
17:43:05  <sgk>  and that's in the default load list 
17:43:12  <sgk>  at least in current trunk 
17:43:24  <jason_at_intel_>      I might be out of date on this... 
17:43:31  <[GregNoel](GregNoel)>     Garyo, yes, I seem to recall an issue to combine Install{,As}, Copy*, and Textfile into one Tool. 
17:43:50  <jason_at_intel_>      last time i tried it.. it was not there by default 
17:44:35  <Garyo>        Ah yes, I see in Tool/<ins>init</ins>.py there's even a relevant comment.  But it does look like it should be on by default.  I'll check. 
17:44:42  <[GregNoel](GregNoel)>     We're getting off-point... 
17:44:58  <sgk>  yes 
17:45:00  <sgk>  back to 2653 
17:45:10  <sgk>  2.1 p2 sgk 
17:45:16  <sgk>  any objections ? 
17:45:25  <[GregNoel](GregNoel)>     works for me; done 
17:45:27  <jason_at_intel_>      nope 
17:45:29  <Garyo>        good 
17:45:31  <[GregNoel](GregNoel)>     2654 fixed by Steven 
17:45:31  <[GregNoel](GregNoel)>     2655 
17:46:05  <sgk>  honestly not sure what to do here 
17:46:22  <sgk>  i'd like to get rid of os.chdir(), but the backwards-compatibility issues are scary 
17:46:25  <jason_at_intel_>      so as i see it .. no os.chdir is best .. but that means removing an API 
17:46:28  <[GregNoel](GregNoel)>     Steven's point is good; it means that things like need to be implemented before we can do this. 
17:47:01  <Garyo>        That'd be a big project and change for users.  Is this patch useful in the meantime? 
17:47:04  <sgk>  and we have to go through a deprecation cycle to remove the ability to just do an open('file', 'r') and have it interpreted relative to the SConscript directory 
17:47:05  <jason_at_intel_> 
17:47:35  <sgk>  jason_at_intel:  File nodes should, from the start, have implemented methods like Python file handles 
17:47:42  <sgk>  .read(), .readlines(), etc. 
17:48:09  <jason_at_intel_>      ok, so this means that we should preffer to use only SCons file API, not systems one 
17:48:42  <Garyo>        That would be necessary if we wanted to get rid of os.chdir() completely.  But I think that's fraught with peril. 
17:48:53  <Garyo>        as well as being more work than we think. 
17:49:41  <jason_at_intel_>      I guess i will see how bad this can be in Parts... 
17:50:01  <jason_at_intel_>      I will set it up to not have Scons chdir 
17:49:52  <Garyo>        Frankly I think this patch is very sensible as it stands. 
17:50:22  <jason_at_intel_>      :-) 
17:50:03  <sgk>  back to Garyo's question:  i think the patch is useful in the meantime 
17:50:15  <sgk>  so let's apply it for 2.1 
17:50:26  <sgk>  and we should have a new issue to get rid of os.chdir() ? 
17:50:19  <[GregNoel](GregNoel)>     If we're going to change the API in the direction of no os.chdir(), I'd worry about applying this as a band-aid in the short term. 
17:50:35  <Garyo>        Greg: why? 
17:51:17  <[GregNoel](GregNoel)>     Two changes to the same API.  And it does make a non-backward-compatible change, so it'll require deprecation... 
17:51:57  <sgk>  two changes? 
17:51:56  <jason_at_intel_>      I think this need many steps 
17:52:02  <Garyo>        Maybe I didn't look carefully.  I thought it doesn't change the API, just what dir you're in when duplicate=False. 
17:52:04  <sgk>  oh 
17:52:05  <[GregNoel](GregNoel)>     sgk, why a new issue?  Isn't 824 sufficient? 
17:52:28  <sgk>  oh, i forgot about 824 
17:52:40  <sgk>  that's sufficient, just so long as we track that issue 
17:52:51  <jason_at_intel_>      add stuff, make the handling more consistent for os.* stuff and migrate overtime 
17:52:53  <sgk>  (i mean the general issue of os.chdir()) 
17:52:56  <Garyo>        I think changing to the build dir when duplicate=False is just a bug, pure & simple.  The first build gets one dir, the second gets a different one. 
17:53:13  <sgk>  yep, i've come around to that 
17:54:00  <[GregNoel](GregNoel)>     But with the patch, the -n case gets different things (assuming I understand it correctly) 
17:54:22  <jason_at_intel_>      I think the patch should be no worse than it is today 
17:54:43  <jason_at_intel_>      even today i can get directory creation with -n 
17:55:08  <sgk>  that doesn't mean we should add more instances of that; it's undesirable behavior 
17:55:11  <jason_at_intel_>      I did fix it with Steve suggestion to not make it worse 
17:55:17  <sgk>  iirc, the latest incarnation of the patch fixed that 
17:55:22  <sgk>  yeah 
17:55:45  <[GregNoel](GregNoel)>     No, I said -n gets different results; it's run in the source directory. 
17:56:06  <jason_at_intel_>      but there is some reason why it is made.. I did not remove that code.. it seemed tightly coupled with something i did not understand 
17:56:28  <sgk>  tight coupling r us... :-( 
17:56:57  <jason_at_intel_>      So Greg i don't understand your issue 
17:57:17  <sgk>  i think it's okay if -n behaves slightly differently 
17:57:22  <jason_at_intel_>      with -n and a 100% fresh build you always get the same results 
17:57:54  <sgk>  -n is usually a quick sanity check to see what might happen 
17:58:26  <jason_at_intel_>      only in the case when the directory should not have been made is it different with the patch.. I feel that it better form the user point of view 
17:58:40  <sgk>  that makes sense to me 
17:58:41  <[GregNoel](GregNoel)>     sgk, maybe, but I'd be surprised if it said it was going to do something and did something else... 
17:58:58  <Garyo>        Greg: I'm not following you 
17:59:13  <Garyo>        What are you telling it, and what is it doing? 
17:59:24  <sgk>  yeah, that's a fair point, but I don't think it outweighs having another honest-to-goodness use case that's outright broken 
18:00:03  <[GregNoel](GregNoel)>     I'll not push the point, but I suspect it'll end up as another FAQ. 
18:00:34  <sgk>  fair enough 
18:00:28  <Garyo>        ok, I think we beat this one into the ground :-) 
18:00:39  <[GregNoel](GregNoel)>     Yeah, decision? 
18:00:50  <jason_at_intel_>      so resolution? 
18:01:03  <sgk>  2.1 p3 sk, i'll integrate 
18:01:16  <sgk>  i already have it teed up in a checked out tree 
18:01:16  <[GregNoel](GregNoel)>     done 
18:01:19  <jason_at_intel_>      add patch, or wait for a no os.chdir solution? 
18:01:27  <Garyo>        add patch 
18:01:29  <jason_at_intel_>      +1 
18:02:24  <[GregNoel](GregNoel)>     Ok, onward....  2391? 
18:02:25  <sgk>  do we plow on a bit, or are we done for the night? 
18:02:33  <jason_at_intel_>      2391? 
18:02:35  <sgk>  i probably have about 15 more minutes 
18:02:49  <Garyo>        let's keep on til sgk has to leave 
18:02:59  <[GregNoel](GregNoel)>     sgk, there are a couple that are consensus or close to it; we should at least hit those. 
18:03:09  <sgk>  onward 
18:02:46  <sgk>  2391:  2.2 p2 sgk 
18:03:26  <[GregNoel](GregNoel)>     2391, have at it. 
18:03:47  <sgk>  2221:  2.1 p3 sgk (since I've been looking at subst()) 
18:04:07  <sgk>  if loonycyborg's patch doesn't work cleanly, i'll come back w/potential adjustment 
18:03:59  <Garyo>        agreed 
18:04:01  <[GregNoel](GregNoel)>     done 
18:04:11  <[GregNoel](GregNoel)>     1891, skip 
18:04:30  <jason_at_intel_>      oh we see 2153 alot 
18:05:28  <sgk>  jason_at_intel:  if you want to try to tackle 2153, sync up w/me off-line 
18:05:37  <jason_at_intel_>      Done :-) 
18:05:48  <sgk>  i think i can describe a general approach to a fix, if you want to do the heavy lifting 
18:04:29  <[GregNoel](GregNoel)>     2145, same as 2221? 
18:04:50  <sgk>  2145, yes:  2.1 p3 sgk 
18:04:55  <Garyo>        agreed 
18:04:55  <[GregNoel](GregNoel)>     done 
18:05:07  <[GregNoel](GregNoel)>     2153, skip 
18:05:19  <[GregNoel](GregNoel)>     2171 dup 
18:05:45  <[GregNoel](GregNoel)>     2351, what milestone and priority? 
18:06:02  <sgk>  you mean 2357? 
18:06:03  <[GregNoel](GregNoel)>     er, 2357 
18:06:33  <sgk>  2.1 p2 for that first step? 
18:07:10  <[GregNoel](GregNoel)>     Hmmm....  Yeah, I think so. 
18:07:48  <[GregNoel](GregNoel)>     I'd rather it were a bit later, though... 
18:08:10  <Garyo>        2.2 is ok w/ me, 2.1 is chock full already 
18:08:28  <sgk>  yeah, 2.2 is fine 
18:09:00  <sgk>  2.2 p2 
18:08:32  <[GregNoel](GregNoel)>     done 
18:08:40  <[GregNoel](GregNoel)>     2375 
18:09:02  <[GregNoel](GregNoel)>     ...which will be the last one; none of the rest have significant comments. 
18:09:05  <Garyo>        anytime is ok 
18:10:06  <Garyo>        Greg: agreed, the rest are for next time. 
18:10:14  <Garyo>        Good progress! 
18:10:14  <[GregNoel](GregNoel)>     I'd rather make it a hard deadline; 'anytime' is almost as bad as 'research' 
18:10:31  <sgk>  i like garyo's 2.2 p2 suggestion 
18:10:37  <sgk>  too much already in 2.1 
18:10:43  <[GregNoel](GregNoel)>     done and done. 
18:10:47  <sgk>  but it's a good idea to clean up the command line this way thereafter 
18:11:10  <[GregNoel](GregNoel)>     concur 
18:11:35  <sgk>  all right, good stuff tonight 
18:11:48  <Garyo>        I feel like 2.1 is going to be really good. 
18:12:05  <[GregNoel](GregNoel)>     agreed 
18:12:04  <sgk>  cool 
18:12:05  <jason_at_intel_>      I am looking forward to it myself 
18:12:17  <sgk>  jason_at_intel:  i'll try to look harder at your is_up_to_date() optimization 
18:12:30  <sgk>  at first glance it seems fine in principal 
18:12:57  <jason_at_intel_>      Sure... I need to review stuff gary talked about 
18:13:07  <Garyo>        sgk: if he's right that is a HUGE time savings. 
18:13:16  <sgk>  yeah 
18:13:16  <Garyo>        Definitely worth the investigation. 
18:13:38  <jason_at_intel_>      It might be easier for me to do some stuff in Parts as i have components which gives me some bounds 
18:13:38  <sgk>  i'll run it through the tests and see what pops out, my guess is there may be a few corner cases that depend on the behavior 
18:13:51  <sgk>  but if so, it'd be worth finding other ways to deal with them 
18:14:12  <jason_at_intel_>      but it would be great if we could pre-make node with out and env, or change it with out issues 
18:14:21  <jason_at_intel_>      or pickle the node 
18:14:59  <Garyo>        scary 
18:15:05  <jason_at_intel_>      anyways.. I will see what the tests show me tomorrow 
18:15:35  <jason_at_intel_>      I will sync with you on the visit steve this week 
18:15:48  <jason_at_intel_>      might want to know of a good hotel in the area 
18:15:51  <sgk>  jason_at_intel:  okay, thanks 
18:15:01  <sgk>  any other last-minute pressing issues? 
18:15:07  <Garyo>        none 4 me 
18:15:16  <[GregNoel](GregNoel)>     nor me 
18:15:24  <Garyo>        I'll be gone til the 18th starting tomorrow 
18:15:43  <sgk>  vacation or work ? 
18:15:49  <Garyo>        vacation, Madrid 
18:16:04  <sgk>  great, have fun! 
18:16:04  <jason_at_intel_>      have fun Gary! 
18:16:09  <Garyo>        will do! 
18:15:55  <[GregNoel](GregNoel)>     Garyo, Next party is after that; we'll see you then. 
18:16:04  <Garyo>        Greg: sounds good. 
18:16:14  <[GregNoel](GregNoel)>     Garyo, Spain or Mississippi? 
18:16:19  <sgk>  'night all 
18:16:25  *      sgk (~[]( has left #SCONS 
18:16:32  <Garyo>        Spain -- actually I'm giving a talk, but it's mostly vacation anyway. 
18:16:41  <[GregNoel](GregNoel)>     Have fun... 
18:16:45  <jason_at_intel_>      night! and thanks! 
18:16:54  <Garyo>        'night all. 
18:17:00  <[GregNoel](GregNoel)>     g'night 
18:17:09  *      Garyo (~[]( has left #SCONS 
18:17:18  *      jason_at_intel_ has quit (Quit: [ChatZilla](ChatZilla) 0.9.86 [Firefox 3.6.6/20100625231939])