IrcLog2010 07 06
William Deegan edited this page Jan 14, 2016
·
2 revisions
16:49:42 * Garyo (~[chatzilla@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com](mailto:chatzilla@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com)) has joined #SCONS
16:49:43 * jason_at_intel_ (~[chatzilla@210.sub-69-97-59.myvzw.com](mailto:chatzilla@210.sub-69-97-59.myvzw.com)) has joined #SCONS
16:55:13 * sgk_ (~[sgk@c-24-4-65-89.hsd1.ca.comcast.net](mailto:sgk@c-24-4-65-89.hsd1.ca.comcast.net)) 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/filesystem.py
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 Node.read() 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_> node.read()??
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 file.open 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 (~[sgk@c-24-4-65-89.hsd1.ca.comcast.net](mailto:sgk@c-24-4-65-89.hsd1.ca.comcast.net)) 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 (~[chatzilla@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com](mailto:chatzilla@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com)) has left #SCONS
18:17:18 * jason_at_intel_ has quit (Quit: [ChatZilla](ChatZilla) 0.9.86 [Firefox 3.6.6/20100625231939])