Please note:The SCons wiki is in read-only mode due to ongoing spam/DoS issues. Also, new account creation is currently disabled. We are looking into alternative wiki hosts.
   1 16:49:42 *	Garyo (~chatzilla@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #SCONS
   2 16:49:43 *	jason_at_intel_ (~chatzilla@210.sub-69-97-59.myvzw.com) has joined #SCONS
   3 16:55:13 *	sgk_ (~sgk@c-24-4-65-89.hsd1.ca.comcast.net) has joined #SCONS
   4 16:56:18 *	sgk_ is now known as sgk
   5 17:05:20 *	GregNoel has arrived...
   6 17:06:51 <GregNoel>	Lots to do today; shall we start?
   7 17:06:59 <Garyo>	I'm ready
   8 17:07:02 <sgk>	let's go
   9 17:07:05 <jason_at_intel_>	ready
  10 17:07:04 <GregNoel>	2443 closed by Steven
  11 17:07:04 <GregNoel>	2570 consensus 2.1 p1 Gary
  12 17:07:04 <GregNoel>	2551 consensus 2.1 p4 Steven
  13 17:07:04 <GregNoel>	That clears off the 1.3 issues
  14 17:07:04 <GregNoel>	2549 does Russel have commit?
  15 17:07:46 <Garyo>	2549: not that I've seen
  16 17:07:57 <sgk>	i don't believe he does
  17 17:08:11 <GregNoel>	so someone will have to proxy it for him
  18 17:08:44 <sgk>	i can do the integration
  19 17:09:03 <Garyo>	thanks, sounds good
  20 17:09:36 <GregNoel>	done
  21 17:09:40 <GregNoel>	2560 consensus anytime p1 Greg
  22 17:09:40 <GregNoel>	2564 consensus Gary+Greg this summer
  23 17:09:40 <GregNoel>	2636 If Russel doesn't want it, I can go with future p3.
  24 17:09:40 <sgk>	do we want a new issue to track the idea of a WhereIs() for LIBPATH ?
  25 17:09:51 <GregNoel>	Yes, I'll create it.
  26 17:09:55 <sgk>	thnx
  27 17:10:03 <Garyo>	2564: will have to be August for me, ok Greg?
  28 17:10:40 <GregNoel>	Garyo, late August is fine; first week is family holiday
  29 17:10:57 <Garyo>	ok.  Shouldn't be all that painful I think.
  30 17:11:25 <GregNoel>	2637 fixed by Greg
  31 17:11:25 <GregNoel>	2638 consensus anytime p2 Greg
  32 17:11:25 <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).
  33 17:12:02 <Garyo>	me too
  34 17:12:06 <sgk>	me three
  35 17:12:34 <sgk>	hmm...
  36 17:12:52 <sgk>	would it help or hurt if we also put the research issues on the list to review every bug party ?
  37 17:12:54 <sgk>	status update, etc.
  38 17:12:59 <jason_at_intel_>	Don't know enough ...
  39 17:13:05 <sgk>	might provide additional incentive to look at them instead of letting them languish
  40 17:13:06 <Garyo>	Eek, then we'd have to *do* them! :-)
  41 17:13:10 <sgk>	if only to get them off the list
  42 17:13:16 <sgk>	:-)
  43 17:13:30 <GregNoel>	sgk, not a bad idea; we certainly need some concept of a time limit.
  44 17:13:51 <Garyo>	Greg: time limit ++
  45 17:13:58 <sgk>	agreed
  46 17:14:25 <jason_at_intel_>	+1
  47 17:14:25 <Garyo>	So... sgk, still want to take this one as research?
  48 17:14:37 <sgk>	2648? yes
  49 17:14:39 <GregNoel>	Maybe p1 issues are reviewed, and each party increases the priority of non-p1 issues?
  50 17:15:00 <Garyo>	Greg: I was almost going to propose that but didn't want to make more work.
  51 17:15:06 <Garyo>	But I like it.
  52 17:15:25 <GregNoel>	Yeah, it'd be a hassle, but it might be worth it
  53 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.
  54 17:15:19 <sgk>	of research issues, yes?
  55 17:15:23 <sgk>	not all issues
  56 17:15:41 <GregNoel>	sgk, yes, only research issues.
  57 17:15:59 <sgk>	if it can be done without too much extra hassle, it sounds worthwhile
  58 17:16:02 <GregNoel>	So, 2648, what priority?
  59 17:16:28 <Garyo>	p3 or p4, since it's user error anyway
  60 17:16:47 <GregNoel>	either works for me
  61 17:16:45 <sgk>	since i'm on hook, p4
  62 17:16:53 <GregNoel>	p4, done
  63 17:16:55 <sgk>	that'll give me three bug partys before we review it again... :-)
  64 17:17:21 <GregNoel>	2649 Steven just updated it and I haven't had time to look at it.  Are there other opinions?
  65 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
  66 17:17:49 <sgk>	Garyo++
  67 17:19:01 <GregNoel>	Was that about 2649 or still on the research issues?
  68 17:19:07 <Garyo>	2649: sounds like greg & sk are figuring out if it's an issue or not, right?
  69 17:19:20 <jason_at_intel_>	it seems like this need to be looked into more
  70 17:19:26 <GregNoel>	yes, but what to do with it?
  71 17:19:35 <sgk>	Jason_at_intel:  well, that's kind of what we're doing with it... :-)
  72 17:19:43 <GregNoel>	review next time?
  73 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
  74 17:20:03 <jason_at_intel_>	:-)
  75 17:20:19 <Garyo>	Jason: but look at this issue.  Steven thinks there's nothing wrong with Alias once 2443 is fixed.
  76 17:20:39 <sgk>	well, more "hoping" than "thinking," but yes in principal... :-)
  77 17:21:03 <sgk>	Jason_at_intel:  we need an actual test case
  78 17:21:11 <sgk>	i'm too close to the code to create one
  79 17:21:12 <jason_at_intel_>	right.. so do we want to link these items?
  80 17:21:22 <Garyo>	Your dep graph is pretty clear there.  (Maybe we should tag Alias nodes visibly in dep graphs??)
  81 17:21:49 <sgk>	Garyo:  yeah, we should probably have a Python-like <Alias 'sub1/a.lib'> or some such
  82 17:21:58 <sgk>	or at least a mode that displays stuff like that
  83 17:22:20 <sgk>	well, the items aren't linked per se
  84 17:22:26 <Garyo>	I'd like that, for clarity.  I'd be happy with (Alias) after the name.
  85 17:22:46 <sgk>	the fix for the previous issue of using Depends() without Builders is already committed
  86 17:22:41 <GregNoel>	The curve here is that Alias() can supposedly have an action.
  87 17:23:09 <Garyo>	Greg: you're right, I'm just sidetracking.
  88 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)
  89 17:23:26 <GregNoel>	point.
  90 17:24:26 <sgk>	The fix I submitted for no-Builder Depends() isn't specific to any node type
  91 17:24:28 <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.
  92 17:24:47 <sgk>	so there's a decent chance that it makes the Alias() case better, at least
  93 17:25:03 <jason_at_intel_>	it seems that a test case should not be to hard for this one
  94 17:25:30 <sgk>	cool, if you can come up with one, that would be great
  95 17:25:49 <Garyo>	OK, how about we close this one next time if no test case shows up?
  96 17:26:01 <GregNoel>	I think time is up on this issue; review next time?
  97 17:26:17 <GregNoel>	Or close it... {;-}
  98 17:26:01 <sgk>	that sounds good
  99 17:26:21 <jason_at_intel_>	is it correct to say this bug is related to stuff like :
 100 17:26:22 <jason_at_intel_>	x=env.Alias("foo",action)
 101 17:26:23 <jason_at_intel_>	env.Depends(env.Alias(boo,x))
 102 17:26:51 <Garyo>	huh?
 103 17:27:06 <jason_at_intel_>	last line should be env.Depends(env.Alias(boo),x)
 104 17:27:20 <Garyo>	What's boo?
 105 17:27:31 <jason_at_intel_>	you can't maps depends to to alias
 106 17:27:32 <jason_at_intel_>	"boo"
 107 17:27:39 <jason_at_intel_>	just an alias name
 108 17:27:59 <jason_at_intel_>	foo has an actions.. so i can say Scons foo
 109 17:28:04 <Garyo>	so the Alias "boo" depends on the Alias "foo" which has an action?
 110 17:28:08 <jason_at_intel_>	but i can say't scons boo
 111 17:28:16 <sgk>	jason_at_intel:  if that's a use case that fails, sure
 112 17:28:37 <jason_at_intel_>	but why?
 113 17:28:40 <Garyo>	jason: if it really fails, put it in this bug. (imho)
 114 17:28:50 <jason_at_intel_>	Sure.
 115 17:28:52 <sgk>	the problem is that on our own we're not successfully characterizing what exactly "this bug" is... :-)
 116 17:29:07 <Garyo>	#2649
 117 17:29:12 <GregNoel>	2650 I'm also interested in this issue, so it could go on my plate instead.
 118 17:29:53 <Garyo>	2650: if this works it could be a huge enhancement!
 119 17:30:04 <sgk>	GregNoel:  if you want 2650, that'd be great
 120 17:30:05 <jason_at_intel_>	+1 for 2650
 121 17:30:41 *	sgk changes the relevant cell in the spreadsheet...
 122 17:30:20 <Garyo>	I don't care if you make a SEP for it really.
 123 17:30:47 <GregNoel>	Well, I'm beginning to agree with you after the discussion with Russel.
 124 17:31:22 <Garyo>	I found the SEP thing really useful when doing the site_scons dirs.
 125 17:31:17 <jason_at_intel_>	:-)
 126 17:31:23 <jason_at_intel_>	like the additions
 127 17:31:51 <GregNoel>	OK, draft a SEP, review next time?
 128 17:31:57 <Garyo>	great
 129 17:32:00 <sgk>	sounds good
 130 17:32:12 <GregNoel>	done
 131 17:32:15 <GregNoel>	2651
 132 17:33:08 <Garyo>	I could probably look at this for 2.2
 133 17:33:13 <Garyo>	or 2.3
 134 17:33:27 <Garyo>	but not 2.1
 135 17:33:55 <Garyo>	I have plenty of rpm-based machines around
 136 17:34:05 <Garyo>	2.3 p4 garyo
 137 17:34:11 <sgk>	works for me
 138 17:34:13 <GregNoel>	works for me
 139 17:34:31 <GregNoel>	(jinx)
 140 17:34:20 <GregNoel>	2652 Gary can have it, but what priority?
 141 17:34:55 <jason_at_intel_>	does this have to be loaded in the default builder to work?
 142 17:35:03 <sgk>	p3
 143 17:35:05 <Garyo>	I have a bunch of other things, p3 is good for me
 144 17:35:14 <Garyo>	Jason: ?
 145 17:35:28 <GregNoel>	p3 works for me; done
 146 17:35:45 <GregNoel>	2653
 147 17:35:50 <sgk>	jason_at_intel:  "does this have to be loaded..."  "this" == ?
 148 17:35:56 <Garyo>	2653: how do you make a symlink on windows like that?
 149 17:36:04 <sgk>	he doesn't make it on Windows
 150 17:36:09 <sgk>	it's an NFS-mounted file system
 151 17:36:18 <sgk>	so it was made on Linux/BSD/what have you
 152 17:36:21 <jason_at_intel_>	I thought copyAs was a tool that has to be loaded to so it can be called
 153 17:36:24 <Garyo>	omg
 154 17:36:31 <jason_at_intel_>	that is why i am making a CCopy builder in Parts
 155 17:36:36 <sgk>	but it makes SCons gag, and we should at least be more graceful than a stack trace
 156 17:37:03 <jason_at_intel_>	so the gag might be python itself
 157 17:37:19 <jason_at_intel_>	windows has some rules about how files should be open
 158 17:37:28 <sgk>	give 2653 to me, my systems at work are set up so I can test this
 159 17:37:32 <GregNoel>	I'm lost; what are we talking about?
 160 17:37:40 <jason_at_intel_>	and the standard way python does it violate the rules
 161 17:37:50 <Garyo>	I'm talking about 2563
 162 17:37:50 <sgk>	2653
 163 17:37:55 <jason_at_intel_>	2653?
 164 17:38:11 <Garyo>	sorry 2653
 165 17:38:37 <jason_at_intel_>	Anyways.. I been working on work around to the issue in Parts
 166 17:38:42 <GregNoel>	OK, then why does CopyAs() have to be loaded in 2653?
 167 17:39:11 <jason_at_intel_>	that was a different issue :-)
 168 17:39:28 <jason_at_intel_>	I thought copyAs was a tool that was not loaded by default
 169 17:39:32 <jason_at_intel_>	so the user could not call it
 170 17:39:49 <jason_at_intel_>	but i could be wrong
 171 17:39:46 <GregNoel>	What does that have to do with documenting it?
 172 17:40:10 <Garyo>	Re: 2653, Justin has just replied w/ how he makes these symlinks (mklink /d).
 173 17:40:16 <sgk>	GregNoel:  nothing directly, talk of documenting CopyTo()/CopyAs() prompted jason_at_intel to wonder about needing to load it
 174 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
 175 17:40:47 <sgk>	Garyo:  understood that more modern Windows file systems can make symlink-like things
 176 17:41:03 <sgk>	I'll try to look at that behavior, too
 177 17:41:21 <jason_at_intel_>	so on windows.. with 2653... you all know who to make symlinks and hardlinks
 178 17:42:22 <Garyo>	Jason: I see your point re: CopyTo/CopyAs.  I'll note that in the doc.  However: shouldn't they just be loaded standard like Copy?
 179 17:42:39 <Garyo>	Why aren't they?
 180 17:42:41 <sgk>	it looks to me like CopyTo() / CopyAs() are loaded by default
 181 17:42:47 <sgk>	they're in Tool/filesystem.py
 182 17:43:05 <sgk>	and that's in the default load list
 183 17:43:12 <sgk>	at least in current trunk
 184 17:43:24 <jason_at_intel_>	I might be out of date on this...
 185 17:43:31 <GregNoel>	Garyo, yes, I seem to recall an issue to combine Install{,As}, Copy*, and Textfile into one Tool.
 186 17:43:50 <jason_at_intel_>	last time i tried it.. it was not there by default
 187 17:44:35 <Garyo>	Ah yes, I see in Tool/__init__.py there's even a relevant comment.  But it does look like it should be on by default.  I'll check.
 188 17:44:42 <GregNoel>	We're getting off-point...
 189 17:44:58 <sgk>	yes
 190 17:45:00 <sgk>	back to 2653
 191 17:45:10 <sgk>	2.1 p2 sgk
 192 17:45:16 <sgk>	any objections ?
 193 17:45:25 <GregNoel>	works for me; done
 194 17:45:27 <jason_at_intel_>	nope
 195 17:45:29 <Garyo>	good
 196 17:45:31 <GregNoel>	2654 fixed by Steven
 197 17:45:31 <GregNoel>	2655
 198 17:46:05 <sgk>	honestly not sure what to do here
 199 17:46:22 <sgk>	i'd like to get rid of os.chdir(), but the backwards-compatibility issues are scary
 200 17:46:25 <jason_at_intel_>	so as i see it .. no os.chdir is best .. but that means removing an API
 201 17:46:28 <GregNoel>	Steven's point is good; it means that things like Node.read() need to be implemented before we can do this.
 202 17:47:01 <Garyo>	That'd be a big project and change for users.  Is this patch useful in the meantime?
 203 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
 204 17:47:05 <jason_at_intel_>	node.read()??
 205 17:47:35 <sgk>	jason_at_intel:  File nodes should, from the start, have implemented methods like Python file handles
 206 17:47:42 <sgk>	.read(), .readlines(), etc.
 207 17:48:09 <jason_at_intel_>	ok, so this means that we should preffer to use only SCons file API, not systems one
 208 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.
 209 17:48:53 <Garyo>	as well as being more work than we think.
 210 17:49:41 <jason_at_intel_>	I guess i will see how bad this can be in Parts...
 211 17:50:01 <jason_at_intel_>	I will set it up to not have Scons chdir
 212 17:49:52 <Garyo>	Frankly I think this patch is very sensible as it stands.
 213 17:50:22 <jason_at_intel_>	:-)
 214 17:50:03 <sgk>	back to Garyo's question:  i think the patch is useful in the meantime
 215 17:50:15 <sgk>	so let's apply it for 2.1
 216 17:50:26 <sgk>	and we should have a new issue to get rid of os.chdir() ?
 217 17:50:19 <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.
 218 17:50:35 <Garyo>	Greg: why?
 219 17:51:17 <GregNoel>	Two changes to the same API.  And it does make a non-backward-compatible change, so it'll require deprecation...
 220 17:51:57 <sgk>	two changes?
 221 17:51:56 <jason_at_intel_>	I think this need many steps
 222 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.
 223 17:52:04 <sgk>	oh
 224 17:52:05 <GregNoel>	sgk, why a new issue?  Isn't 824 sufficient?
 225 17:52:28 <sgk>	oh, i forgot about 824
 226 17:52:40 <sgk>	that's sufficient, just so long as we track that issue
 227 17:52:51 <jason_at_intel_>	add file.open stuff, make the handling more consistent for os.* stuff and migrate overtime
 228 17:52:53 <sgk>	(i mean the general issue of os.chdir())
 229 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.
 230 17:53:13 <sgk>	yep, i've come around to that
 231 17:54:00 <GregNoel>	But with the patch, the -n case gets different things (assuming I understand it correctly)
 232 17:54:22 <jason_at_intel_>	I think the patch should be no worse than it is today
 233 17:54:43 <jason_at_intel_>	even today i can get directory creation with -n
 234 17:55:08 <sgk>	that doesn't mean we should add more instances of that; it's undesirable behavior
 235 17:55:11 <jason_at_intel_>	I did fix it with Steve suggestion to not make it worse
 236 17:55:17 <sgk>	iirc, the latest incarnation of the patch fixed that
 237 17:55:22 <sgk>	yeah
 238 17:55:45 <GregNoel>	No, I said -n gets different results; it's run in the source directory.
 239 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
 240 17:56:28 <sgk>	tight coupling r us... :-(
 241 17:56:57 <jason_at_intel_>	So Greg i don't understand your issue
 242 17:57:17 <sgk>	i think it's okay if -n behaves slightly differently
 243 17:57:22 <jason_at_intel_>	with -n and a 100% fresh build you always get the same results
 244 17:57:54 <sgk>	-n is usually a quick sanity check to see what might happen
 245 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
 246 17:58:40 <sgk>	that makes sense to me
 247 17:58:41 <GregNoel>	sgk, maybe, but I'd be surprised if it said it was going to do something and did something else...
 248 17:58:58 <Garyo>	Greg: I'm not following you
 249 17:59:13 <Garyo>	What are you telling it, and what is it doing?
 250 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
 251 18:00:03 <GregNoel>	I'll not push the point, but I suspect it'll end up as another FAQ.
 252 18:00:34 <sgk>	fair enough
 253 18:00:28 <Garyo>	ok, I think we beat this one into the ground :-)
 254 18:00:39 <GregNoel>	Yeah, decision?
 255 18:00:50 <jason_at_intel_>	so resolution?
 256 18:01:03 <sgk>	2.1 p3 sk, i'll integrate
 257 18:01:16 <sgk>	i already have it teed up in a checked out tree
 258 18:01:16 <GregNoel>	done
 259 18:01:19 <jason_at_intel_>	add patch, or wait for a no os.chdir solution?
 260 18:01:27 <Garyo>	add patch
 261 18:01:29 <jason_at_intel_>	+1
 262 18:02:24 <GregNoel>	Ok, onward....  2391?
 263 18:02:25 <sgk>	do we plow on a bit, or are we done for the night?
 264 18:02:33 <jason_at_intel_>	2391?
 265 18:02:35 <sgk>	i probably have about 15 more minutes
 266 18:02:49 <Garyo>	let's keep on til sgk has to leave
 267 18:02:59 <GregNoel>	sgk, there are a couple that are consensus or close to it; we should at least hit those.
 268 18:03:09 <sgk>	onward
 269 18:02:46 <sgk>	2391:  2.2 p2 sgk
 270 18:03:26 <GregNoel>	2391, have at it.
 271 18:03:47 <sgk>	2221:  2.1 p3 sgk (since I've been looking at subst())
 272 18:04:07 <sgk>	if loonycyborg's patch doesn't work cleanly, i'll come back w/potential adjustment
 273 18:03:59 <Garyo>	agreed
 274 18:04:01 <GregNoel>	done
 275 18:04:11 <GregNoel>	1891, skip
 276 18:04:30 <jason_at_intel_>	oh we see 2153 alot
 277 18:05:28 <sgk>	jason_at_intel:  if you want to try to tackle 2153, sync up w/me off-line
 278 18:05:37 <jason_at_intel_>	Done :-)
 279 18:05:48 <sgk>	i think i can describe a general approach to a fix, if you want to do the heavy lifting
 280 18:04:29 <GregNoel>	2145, same as 2221?
 281 18:04:50 <sgk>	2145, yes:  2.1 p3 sgk
 282 18:04:55 <Garyo>	agreed
 283 18:04:55 <GregNoel>	done
 284 18:05:07 <GregNoel>	2153, skip
 285 18:05:19 <GregNoel>	2171 dup
 286 18:05:45 <GregNoel>	2351, what milestone and priority?
 287 18:06:02 <sgk>	you mean 2357?
 288 18:06:03 <GregNoel>	er, 2357
 289 18:06:33 <sgk>	2.1 p2 for that first step?
 290 18:07:10 <GregNoel>	Hmmm....  Yeah, I think so.
 291 18:07:48 <GregNoel>	I'd rather it were a bit later, though...
 292 18:08:10 <Garyo>	2.2 is ok w/ me, 2.1 is chock full already
 293 18:08:28 <sgk>	yeah, 2.2 is fine
 294 18:09:00 <sgk>	2.2 p2
 295 18:08:32 <GregNoel>	done
 296 18:08:40 <GregNoel>	2375
 297 18:09:02 <GregNoel>	...which will be the last one; none of the rest have significant comments.
 298 18:09:05 <Garyo>	anytime is ok
 299 18:10:06 <Garyo>	Greg: agreed, the rest are for next time.
 300 18:10:14 <Garyo>	Good progress!
 301 18:10:14 <GregNoel>	I'd rather make it a hard deadline; 'anytime' is almost as bad as 'research'
 302 18:10:31 <sgk>	i like garyo's 2.2 p2 suggestion
 303 18:10:37 <sgk>	too much already in 2.1
 304 18:10:43 <GregNoel>	done and done.
 305 18:10:47 <sgk>	but it's a good idea to clean up the command line this way thereafter
 306 18:11:10 <GregNoel>	concur
 307 18:11:35 <sgk>	all right, good stuff tonight
 308 18:11:48 <Garyo>	I feel like 2.1 is going to be really good.
 309 18:12:05 <GregNoel>	agreed
 310 18:12:04 <sgk>	cool
 311 18:12:05 <jason_at_intel_>	I am looking forward to it myself
 312 18:12:17 <sgk>	jason_at_intel:  i'll try to look harder at your is_up_to_date() optimization
 313 18:12:30 <sgk>	at first glance it seems fine in principal
 314 18:12:57 <jason_at_intel_>	Sure... I need to review stuff gary talked about
 315 18:13:07 <Garyo>	sgk: if he's right that is a HUGE time savings.
 316 18:13:16 <sgk>	yeah
 317 18:13:16 <Garyo>	Definitely worth the investigation.
 318 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
 319 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
 320 18:13:51 <sgk>	but if so, it'd be worth finding other ways to deal with them
 321 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
 322 18:14:21 <jason_at_intel_>	or pickle the node
 323 18:14:59 <Garyo>	scary
 324 18:15:05 <jason_at_intel_>	anyways.. I will see what the tests show me tomorrow
 325 18:15:35 <jason_at_intel_>	I will sync with you on the visit steve this week
 326 18:15:48 <jason_at_intel_>	might want to know of a good hotel in the area
 327 18:15:51 <sgk>	jason_at_intel:  okay, thanks
 328 18:15:01 <sgk>	any other last-minute pressing issues?
 329 18:15:07 <Garyo>	none 4 me
 330 18:15:16 <GregNoel>	nor me
 331 18:15:24 <Garyo>	I'll be gone til the 18th starting tomorrow
 332 18:15:43 <sgk>	vacation or work ?
 333 18:15:49 <Garyo>	vacation, Madrid
 334 18:16:04 <sgk>	great, have fun!
 335 18:16:04 <jason_at_intel_>	have fun Gary!
 336 18:16:09 <Garyo>	will do!
 337 18:15:55 <GregNoel>	Garyo, Next party is after that; we'll see you then.
 338 18:16:04 <Garyo>	Greg: sounds good.
 339 18:16:14 <GregNoel>	Garyo, Spain or Mississippi?
 340 18:16:19 <sgk>	'night all
 341 18:16:25 *	sgk (~sgk@c-24-4-65-89.hsd1.ca.comcast.net) has left #SCONS
 342 18:16:32 <Garyo>	Spain -- actually I'm giving a talk, but it's mostly vacation anyway.
 343 18:16:41 <GregNoel>	Have fun...
 344 18:16:45 <jason_at_intel_>	night! and thanks!
 345 18:16:54 <Garyo>	'night all.
 346 18:17:00 <GregNoel>	g'night
 347 18:17:09 *	Garyo (~chatzilla@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has left #SCONS
 348 18:17:18 *	jason_at_intel_ has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.6/20100625231939])
 349 

BugParty/IrcLog2010-07-06 (last edited 2010-07-16 12:34:48 by ip68-7-77-81)