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
