Please note:The SCons wiki is now restored from the attack in March 2013. All old passwords have been invalidated. Please reset your password if you have an account. If you note missing pages, please report them to webmaster@scons.org. Also, new account creation is currently disabled due to an ongoing spam flood (2013/08/27).
   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)