IrcLog2010 07 06

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

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.