1 17:13:48 * Jason_at_intel (n=chatzill@bementil-116.illinois.prairieinet.net) has joined #scons
2 17:24:55 * GregNoel is no longer marked as being away
3 17:31:47 * garyo-home (n=chatzill@209-6-158-38.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #scons
4 17:32:00 <GregNoel> Hi, Gary; Steven's not here yet
5 17:32:06 <garyo-home> Hi, Greg.
6 17:32:16 <garyo-home> I'm still finishing up the spreadsheet.
7 17:32:31 <GregNoel> Yes, I see; I've been following it.
8 17:32:25 <Jason_at_intel> Hi
9 17:32:31 <garyo-home> Hi, Jason.
10 17:39:07 <Jason_at_intel> 2373 look interesting
11 17:39:09 <garyo-home> ok, I'm done with the spreadsheet & ready to go.
12 17:39:36 <garyo-home> Jason: yes, of course it would be more interesting with better tool logic!
13 17:39:58 <Jason_at_intel> yep
14 17:40:07 <garyo-home> In fact I think it's not worth it UNTIL the toolchain stuff is in. But that's a perfect time to add it.
15 17:40:08 <Jason_at_intel> I am about done with my prototype
16 17:40:21 <garyo-home> I'll be interested to see it.
17 17:40:33 <Jason_at_intel> I be interested to finish it :-)
18 17:40:36 <garyo-home> :-)
19 17:40:44 <garyo-home> So the consensus ones are:
20 17:41:40 <garyo-home> 1123, 1449, 1450, 1908, 1914, 2018, 2303.
21 17:41:55 <garyo-home> Non-consensus:
22 17:42:54 <garyo-home> 1632, 2288, 2306, 2357, 2358, 2363, 2364, 2366, 2367, 2370, 2371, 2373.
23 17:43:09 <GregNoel> 1908 isn't consensus; no priority
24 17:43:42 <garyo-home> 1908: you're right, the consensus is priority=?? which is not sufficient.
25 17:44:37 <GregNoel> (I'm always right, remember?)
26 17:43:16 <Jason_at_intel> do you are Greg have an idea of what to call stuff like win32-x86 ( I was going with system_config, and have value such as HOST_SYSTEM and TARGET_SYSTEM)
27 17:44:18 <GregNoel> Whatever GNU configure calls it; more traction on that consensus.
28 17:45:00 <garyo-home> Right, even if we don't use their triples, we should call it something familiar (unless it's terrible :-))
29 17:45:22 <Jason_at_intel> so what does GNU call it?
30 17:45:37 <garyo-home> a Configuration Name. hmm.
31 17:46:02 <garyo-home> Not sure I like that, actually. But config_name isn't so terrible.
32 17:46:08 <GregNoel> get config_guess and run it; it will tell you
33 17:46:12 <Jason_at_intel> ya.. that is bad... configuration is overloaded as is
34 17:46:43 <garyo-home> system_config_name?
35 17:47:03 <Jason_at_intel> I already call is system_config
36 17:47:12 <garyo-home> Jason: is this more for the doc or actually in the sw?
37 17:47:18 <GregNoel> GNU uses platform architecture and OS in some order
38 17:47:39 <garyo-home> Greg: Jason's asking what to call one of those objects (whatever it contains)
39 17:47:49 <garyo-home> http://www.airs.com/ian/configure/configure_4.html#SEC25
40 17:48:06 <Jason_at_intel> yep, the set data is not as important as what to call the object
41 17:48:36 <garyo-home> platform_config is another option
42 17:48:56 <GregNoel> What object? I'm behind here
43 17:49:15 <garyo-home> an object (string) representing one of those GNU configure name triplets
44 17:49:29 <GregNoel> "triplet"
45 17:49:52 <Jason_at_intel> I am good with that. The issue i have with configuration, is that we have configure, and i already have configuration ( as in how the rest of the world see them stuff like release debug.. ie a set of setting with a given name)
46 17:50:17 <garyo-home> That's why system_config or platform_config is better.
47 17:50:56 <Jason_at_intel> So i have been trying to communicate on line in the dev group with Parts work i am doing to make an improved tool chain idea based on my experence and guidance on teh wiki from you and gary
48 17:50:56 <garyo-home> Jason, would users see this mostly in the doc, or in error messages, or ... ?
49 17:51:48 <Jason_at_intel> it would be an var in the env that could be used to control build.
50 17:52:23 <garyo-home> ... but by the time an env is created, it may be too late. (A topic for another time I realize.)
51 17:52:32 <Jason_at_intel> ideally there is a HOST_SYSTEM and a TARGET_SYSTEM ( ie --build and --host for Greg.. only GCC uses --target)
52 17:52:39 <garyo-home> Anyway, how about looking at some of these bugs?
53 17:52:46 <GregNoel> yes
54 17:52:54 <Jason_at_intel> sure... is steve online?
55 17:53:08 <garyo-home> no, but it's 8:52 here.
56 17:53:05 <Jason_at_intel> he is looking at the spreadsheet i think
57 17:53:22 <garyo-home> oh yes, I see him on now.
58 17:53:47 <GregNoel> His spreadsheet cursor hasn't moved for at least two hours
59 17:53:54 <garyo-home> :-(
60 17:54:28 <GregNoel> anyway, 1123 is consensus
61 17:54:29 <garyo-home> Greg, what do you think about my comment on #1632, that it's not really a subst issue?
62 17:54:45 <GregNoel> Let's wait until we get there.
63 17:54:51 <garyo-home> ok, fine.
64 17:55:05 <garyo-home> 1443's consensus
65 17:55:10 <GregNoel> 1449: consensus 2.x p3 +subst
66 17:55:10 <GregNoel> Gary, the prototype code is smarter about curly braces, brackets, and parens. It increments a counter for a "left" occurrence and decrements it for a "right" occurrence. It's stone stupid about whether they match, but if they do, it extracts the right piece.
67 17:55:47 <garyo-home> Great -- it's a real brace parser! (Even if a stupid one, it's better than regex.)
68 17:56:19 <GregNoel> Well, it uses regex to move between and isolate the braces
69 17:56:27 <garyo-home> sure.
70 17:56:53 <Jason_at_intel> that takes skill to write
71 17:57:07 <garyo-home> But in #1632, how would it know to quote the filename that gets %-substituted in? That's a complex expression.
72 17:57:25 <GregNoel> patience
73 17:58:15 <GregNoel> we agree, consensus?
74 17:59:51 <garyo-home> (sorry, had to step out)
75 18:00:16 <GregNoel> consensus on 1449?
76 18:00:36 <garyo-home> ok
77 18:00:42 <GregNoel> 1450: consensus 2.1 p3 DOS person
78 18:00:42 <GregNoel> Brandon's not here, but for the record DOS is a program scheduler masquerading as an operating system; don't confuse it with the real thing. Even changing its name didn't change that fundamental flaw.
79 18:01:11 <Jason_at_intel> rolling my eyes
80 18:01:45 <garyo-home> fine w/ 1450.
81 18:01:52 <GregNoel> 1632: I agree with Steven's point about regression tests, but I'd like to defer this discussion until after we talk about the schedule.
82 18:02:24 <garyo-home> DO you think subst fixes can fix this bug??
83 18:02:42 <GregNoel> yes
84 18:03:01 <garyo-home> Without changing the string in msvc.py? I'd be amazed.
85 18:03:39 <garyo-home> How would it know the difference between the space in the format string, and the spaces in the filename(s)?
86 18:03:37 <GregNoel> I've got an email about half-completed about quoting; someday I'll finish it and send it.
87 18:04:27 <garyo-home> OK, I'll believe you...
88 18:04:32 <GregNoel> 'string' v. ['string w/ spaces']
89 18:04:49 <GregNoel> I think it can be made to work
90 18:04:50 <garyo-home> But isn't this bug about:
91 18:05:15 <garyo-home> subst("/Yu%s /Fp%s" % "filename with spaces")
92 18:05:32 <garyo-home> (sorry, two filenames, each with spaces, as the arg to the format operator)
93 18:05:56 <garyo-home> but maybe you have some magic that can handle it.
94 18:06:32 <garyo-home> If you think so, then I'm OK w/ 2.1 p3 +subst
95 18:06:59 <GregNoel> Hmmm... You have a point; the expression would be evaluated before the subst...
96 18:07:12 <GregNoel> I'll have to look at it again.
97 18:07:17 <garyo-home> right, that's why the OP says the quotes need to be added right there.
98 18:07:52 <GregNoel> You may be right; I was looking at the braces, not the expression
99 18:08:42 <garyo-home> In that case, the patch should be applied.
100 18:09:04 <GregNoel> Hmmm... Let's pass this and come back to it if we have time; we're taking too long on it.
101 18:09:23 <garyo-home> ok fine
102 18:09:44 <GregNoel> 1908: not consensus, need a priority
103 18:09:44 <GregNoel> I think Benoit uses Linux, at least part of the time, but even if the underlying problem is DOS and not us (or maybe _especially_ if it's not us), as long as it keeps happening, I can see the point of checking for it.
104 18:09:44 <GregNoel> Gary, I'm not sure that it's debug-only, but it's a good point that it ought to have "debug" in it if it is.
105 18:09:44 <GregNoel> I like the idea of separating the options into "common" and "advanced" sets, but then I've proposed that before myself. {;-}
106 18:09:44 <GregNoel> However, at the risk of backward incompatibility, could we consider changing all the --cache-option flags into --cache=option and deprecate the old ones in 2.x? (Only --cache-debug=file has a parameter, and we might be able to finesse that somehow.) That would reduce the number of _distinct_ command-line options, at least.
107 18:10:32 <Jason_at_intel> so is this DOS?.. I mean who is using DOS?
108 18:10:47 <GregNoel> you, apparently
109 18:10:48 <garyo-home> 1908: I say p4. cache-verify is only for debugging, I *think* the other one is for fixing corrupt caches.
110 18:11:14 <garyo-home> If you believe the OP, it can occur on any OS due to user error.
111 18:11:22 <GregNoel> yeah, but it's a patch and can corrupt builds
112 18:11:22 <Jason_at_intel> win teh command prompt on windows , while crappy is way better than the old DOS shell
113 18:11:53 <Jason_at_intel> I have not used DOS for years... people seem to confuse DOS with a command prompt
114 18:12:02 <garyo-home> Jason: Greg is using DOS to mean all DOS-derived OSes including Windows.
115 18:12:26 <Jason_at_intel> It is like you saying linux is a BASH, or csh
116 18:12:38 <Jason_at_intel> but that is funny
117 18:12:39 <garyo-home> No, it's like saying linux is Unix.
118 18:12:46 <Jason_at_intel> winnt has not dos roots
119 18:12:55 <Jason_at_intel> it is based on a mainframe
120 18:12:56 <garyo-home> anyway, let's stay on topic.
121 18:13:24 <garyo-home> Can we just say 2.x p4 +easy and note that the option names should have "debug" in them?
122 18:13:41 <Jason_at_intel> sure, the point here is this issue with who we think we can use the command prompt, or a dos prompt?
123 18:13:55 <GregNoel> As I understand cache-verify, it does the build and warns if the content of the cache is different from the built file
124 18:13:57 <Jason_at_intel> cmd.exe which is used today is not command.com
125 18:14:19 <GregNoel> Given that it has a patch, I was thinking p2
126 18:14:38 <garyo-home> split the diff, p3?
127 18:14:46 <GregNoel> Sigh, ok
128 18:15:13 <GregNoel> 1914: consensus 2.x p3 +subst.
129 18:15:13 <GregNoel> Gary, it's not string + string, it's $FOO$BAR where FOO and BAR are strings.
130 18:16:00 <garyo-home> ah, got it.
131 18:16:30 <garyo-home> yup, same old subst whitespace stripping issue.
132 18:16:24 <GregNoel> 2018: consensus?
133 18:16:43 <garyo-home> 2018: agreed.
134 18:16:52 <GregNoel> 2288: Research needs a person and I'd much prefer that someone talk with Philipp _before_ we assign it to him. If we don't assign it to Philipp, we need a milestone and priority for +Easy, probably something in 2.x.
135 18:17:36 <garyo-home> Can you ask him since you already spent some time on the bug? If not, I'll ask him.
136 18:18:02 <GregNoel> I think you (or Steven) should; I don't know him at all.
137 18:18:08 <garyo-home> Just read your comment ("not me!"), I'll do it.
138 18:18:15 <GregNoel> done
139 18:18:46 <GregNoel> 2303: consensus, and as far as Steven got.
140 18:18:53 <garyo-home> 2303 consensus 2.x p2 +Easy
141 18:19:32 <GregNoel> 2306, I still lean toward option two
142 18:20:03 <GregNoel> It seems to me just as flexible as a .common directory and has some other possibilities.
143 18:20:11 <garyo-home> I'm OK w/ that; #2 lets you remove tests, #3 lets you add common code.
144 18:20:42 <GregNoel> #2 also removes common code
145 18:20:33 <garyo-home> Good point, you can add common code w/ #2 too, just doesn't go in a subdir.
146 18:20:46 <garyo-home> Either's fine w/ me.
147 18:21:20 <GregNoel> Defer, I guess; my leaning is not that strong. It's my issue so I can wait until next time.
148 18:21:27 <garyo-home> ok, done.
149 18:21:43 <garyo-home> 2357, I like your patch Greg.
150 18:21:46 <GregNoel> 2357: Gary, 1.3 has a base of Python 1.5.2. Did you mean 2.1? I agree with "everybody" but I'm not sure how to mark that...
151 18:21:58 <garyo-home> Sorry, yes 2.1.
152 18:22:14 <garyo-home> Mark it "steven" but then he signs us all up for it.
153 18:22:36 <GregNoel> {;-} that'll work
154 18:23:18 <garyo-home> ok great, 1.3 p2 "steven (aka everyone)"
155 18:23:26 <GregNoel> done
156 18:23:36 <GregNoel> I think we agree on 2358
157 18:23:40 <garyo-home> 2358: greg, can you invite Ben?
158 18:24:01 <GregNoel> Sure; I've chatted with him on other topics.
159 18:23:53 <garyo-home> I agree he did a good job there.
160 18:24:16 <GregNoel> A marvelous job, indeed.
161 18:24:29 <garyo-home> Good -- 2.1 p2 benmwebb for that one.
162 18:24:37 <garyo-home> (if he'll take it.)
163 18:24:46 <GregNoel> done
164 18:24:48 <GregNoel> 2363: Again, I'd like to defer this discussion until after we talk about the schedule.
165 18:25:14 <garyo-home> ok, probably need to wait for Steven for that discussion.
166 18:25:20 <GregNoel> yes
167 18:25:54 <garyo-home> 2364: I'll follow up the bug report and ask the OP for a test case. Something weird is happening there.
168 18:25:54 <GregNoel> 2364: Gary, it probably looks like it's been reinitialized because his Tool hasn't been selected.
169 18:26:54 <garyo-home> I'm not sure... he put in trace code in WhereIs. I'd like to find out more.
170 18:27:00 <GregNoel> I think Brandon has it right; ask on the user list, and if that turns into a test case, reopen the issue
171 18:27:15 <garyo-home> OK, I'll do that.
172 18:27:42 <GregNoel> Notice the WhereIs() code is hit three times; the last wins, and it's not his.
173 18:27:29 <garyo-home> Close as invalid in the meantime?
174 18:28:35 <garyo-home> I just hate for someone to go away thinking SCons is "perverse" (ok, even if it really is...)
175 18:28:40 <GregNoel> so invalid, move to mailing list?
176 18:28:45 <garyo-home> yes.
177 18:28:58 <garyo-home> I have a note to follow it up.
178 18:28:59 <GregNoel> hopefully toolchain will fix most of that...
179 18:29:07 <garyo-home> Definitely.
180 18:29:04 <GregNoel> done
181 18:29:07 <GregNoel> 2366: Yes, it's a doc change, but when?
182 18:29:43 <garyo-home> Whenever SourceCode gets removed, maybe?
183 18:29:48 <garyo-home> (or earlier)
184 18:30:18 <garyo-home> I'm not 100% sure I understood what was going on though, so don't count on my opinion.
185 18:32:02 <GregNoel> What you want to do is make sure you execute the checkout _before_ you try to build using it. SourceCode() was a hack to get to the right place; we need a better, more flexible, and extensible mechanism.
186 18:30:11 <GregNoel> earlier, so sometime in 2.x. P2?
187 18:30:30 <garyo-home> Sure, 2.x p2 or 2.x p3.
188 18:31:10 <garyo-home> who? don't know.
189 18:32:17 <GregNoel> I guess I have to...
190 18:32:39 <garyo-home> thanks!
191 18:32:44 <GregNoel> np
192 18:32:59 <GregNoel> so 2.x p2 me
193 18:33:01 <Jason_at_intel> I have a possible solution in Parts called VCS
194 18:33:49 <garyo-home> How's it work, in a sentence or 2?
195 18:34:34 <Jason_at_intel> It is an object that grabs data from some source, it however is executed at read time, but build
196 18:34:39 <Jason_at_intel> hmm
197 18:35:18 <garyo-home> I always figured checking everything out before building is more stable anyway.
198 18:35:21 <GregNoel> brb, doorbell
199 18:35:24 <Jason_at_intel> it has the fault that it requires everything to be checkout during teh read, unless you skip it
200 18:36:11 <Jason_at_intel> ya.. the only issue i get at work with it is that people don''t want to check everything out if they only need to build a small piece
201 18:36:21 <garyo-home> I've seen various attempts but nothing as good as "os.system('svn co ...')" in the build script. :-)
202 18:36:28 <Jason_at_intel> we have a small work around for this..
203 18:36:57 <garyo-home> use Repository()?
204 18:36:58 <Jason_at_intel> basically that is the end call.. minus we use Subprocess
205 18:37:10 <Jason_at_intel> honestly can't figure out who to use it correctly
206 18:37:34 <Jason_at_intel> it seem to mess up , like build variants when you duplicate files
207 18:37:59 <Jason_at_intel> I figure it is me, or a SCons bug.. not sure which yet
208 18:38:22 <Jason_at_intel> Tried CacheDir.. but network access can kill build times for people
209 18:38:35 <Jason_at_intel> still hope to get that to work some how better
210 18:39:44 <Jason_at_intel> in the end people suffer in large projects to get it all, then we need the caching to take over to not do stuff it know it does not need to do
211 18:40:17 <Jason_at_intel> anyways SourceCode, messes up with varaint directories for me... same with Glob
212 18:40:52 <garyo-home> Glob is supposed to be designed to handle variants. Submit bug reports if not!
213 18:41:27 <Jason_at_intel> Honestly Dir should be changes to act as a filter i think
214 18:41:45 <garyo-home> ?
215 18:41:46 <Jason_at_intel> i would look at my parts samples that use pattern ( my glob replacement)
216 18:42:04 <Jason_at_intel> SCons has File and Dir
217 18:42:34 <Jason_at_intel> have Dir("mydir", filter,recusive)
218 18:42:55 <garyo-home> It would return a list of nodes instead of the Dir node??
219 18:42:58 <Jason_at_intel> GLob flattens, and lose structure
220 18:43:17 <garyo-home> Glob isn't recursive today.
221 18:43:28 <Jason_at_intel> well this was just a thought. but i think have it return one DIR node
222 18:43:42 <Jason_at_intel> might expand to a list of file later
223 18:43:55 <garyo-home> Dir("mydir") returns the Dir node for "mydir". Seems OK to me.
224 18:44:24 <Jason_at_intel> it is the same as Install() messing up on Dir nodes at times
225 18:44:14 <GregNoel> back, can we proceed?
226 18:44:28 <Jason_at_intel> yes
227 18:44:28 <garyo-home> sure.
228 18:44:34 <GregNoel> so 2.x p2 me
229 18:44:43 <garyo-home> great!
230 18:45:00 <GregNoel> done
231 18:45:03 <GregNoel> 2367, I don't believe multiprocess will solve the problem.
232 18:45:31 <garyo-home> I don't understand all the issues, but is he suggesting python builders w/ chdir get run in a forked process?
233 18:45:49 <GregNoel> I believe so.
234 18:45:56 <garyo-home> That would change semantics.
235 18:46:07 <GregNoel> You noticed!
236 18:46:23 <garyo-home> Global data structures like the DAG for instance.
237 18:46:45 <GregNoel> Not to mention local Python subroutines.
238 18:46:29 <garyo-home> I would not go there.
239 18:46:48 <GregNoel> concur
240 18:47:31 <garyo-home> OK, so doing it your way is clever.
241 18:48:41 <GregNoel> Thanks; it's just the weird way my mind works.
242 18:48:01 <GregNoel> Issue 2124 that he refers to is about creating a pool of processes to run tasks, which will duplicate Jobs.py eventually.
243 18:48:01 <garyo-home> I think there are so many 2.x issues I'm loath to make anything more than p3 unless it's important.
244 18:48:44 <Jason_at_intel> these would run the command
245 18:48:49 <garyo-home> That would work if you could transfer the python code and all its dependencies over, which seems unlikely.
246 18:48:57 <GregNoel> agree
247 18:48:47 <GregNoel> I'm inclined to push it after taskmaster-ng
248 18:48:58 <garyo-home> push til later: agreed.
249 18:49:41 <Jason_at_intel> agree
250 18:49:28 <GregNoel> Let's defer it until after we've had the scheduling discussion.
251 18:49:41 <garyo-home> ok, 2370 then
252 18:49:59 <GregNoel> 2370: If you want to match dotfiles, use Glob(.pat) + Glob(pat).
253 18:50:14 <garyo-home> Yeah, I thought of that, it's probably acceptable.
254 18:50:36 <garyo-home> Specifically Glob('.??*') + Glob('*") to get everything.
255 18:50:49 <GregNoel> yep
256 18:50:26 <GregNoel> invalid, then?
257 18:50:49 <garyo-home> ok, invalid.
258 18:51:11 <GregNoel> done
259 18:51:14 <GregNoel> 2371: Whilst I was exploring this, I discovered that OverrideEnvironment is now derived from Base instead of SubstitutionEnvironment, making it a _very_ expensive object. This change was made 2005-03-18 06:37:06-0700 (4 years ago) by stevenknight with the comment "Fix a regression in handling overridden construction variables when the substitution is called from an Environment.Base class."
260 18:51:14 <GregNoel> Then in the regression tests, we have this:
261 18:51:14 <GregNoel> # Test a number of Base methods through an OverrideEnvironment to
262 18:51:14 <GregNoel> # make sure they handle overridden constructionv variables properly.
263 18:51:14 <GregNoel> # ...
264 18:51:14 <GregNoel> # It's unlikely Clone() will ever be called this way, so let the
265 18:51:14 <GregNoel> # other methods test that handling overridden values works.
266 18:51:14 <GregNoel> #def test_Clone(self):
267 18:51:14 <GregNoel> If there are no objections, I'd like to see if there isn't another way to solve that problem without making OverrideEnvironment so heavyweight. I don't think I'll be able to actually fix the issue here (Clone() of an OverrideEnvironment), but we might want to document (somewhere other than the code?) that not only is an Override() of an OverrideEnvironment valid but also it's the approved technique
268 18:52:37 <garyo-home> Yikes, please do try to look into it.
269 18:52:39 <Jason_at_intel> I would agree with the goal
270 18:52:45 <garyo-home> Could be a big memory saver.
271 18:53:19 <GregNoel> Not so much memory (one unused dict), but all that setup time...
272 18:53:32 <garyo-home> For sure.
273 18:53:57 <GregNoel> I see two techniques as possible:
274 18:53:57 <GregNoel> (1) Use an intermediate class containing those functions that use self.subst() and derive both Base and OverrideEnvironment from it.
275 18:53:57 <GregNoel> (2) Use self[key] to access the environment rather than self._dict[key] and invoke the functions with self pointing to the override. I used this method when I split up ParseConfig(), so I know it works.
276 18:53:57 <GregNoel> Possibly a mixture of both will be needed, but I won't know until I look at it.
277 18:54:46 <garyo-home> Will your newCLVar stuff be related to this a bit?
278 18:55:30 <GregNoel> No, not really. I can look at some of that at the same time, but this is mostly refactoring.
279 18:55:42 <garyo-home> Anyway, so the bug gets marked invalid and you take this as a side task?
280 18:56:01 <GregNoel> yes, or research or anytime...
281 18:56:37 <garyo-home> research should be for something to be retriaged soon though. Anytime is OK w me.
282 18:56:43 <GregNoel> done
283 18:57:01 <GregNoel> 2373, last one, and I need to go soon.
284 18:57:07 <garyo-home> 2373: I was getting off topic, sorry.
285 18:57:35 <Jason_at_intel> that seem to be a big feature
286 18:58:03 <GregNoel> I'm willing to talk to the Debian guy to see what can be done, but I don't think we can do this in isolation.
287 18:57:55 <garyo-home> I like the idea of getting a domain expert involved if possible. Greg, can you follow up?
288 18:58:09 <GregNoel> yes
289 18:58:13 <garyo-home> perfect.
290 18:58:18 <GregNoel> anytime?
291 18:58:23 <garyo-home> sure.
292 18:58:28 <GregNoel> done
293 18:58:35 <garyo-home> ok, that's a wrap then.
294 18:58:47 <garyo-home> thanks!
295 18:58:54 <GregNoel> Yep, dinner is arriving, so I've got to go
296 18:59:01 <GregNoel> cul
297 18:59:02 <Jason_at_intel> later greg
298 18:59:15 * GregNoel has been marked as being away
299 18:59:18 * garyo-home has quit ("ChatZilla 0.9.84 [Firefox 3.0.7/2009021910]")
300 19:12:49 * Jason_at_intel has quit ("ChatZilla 0.9.84 [Firefox 3.0.7/2009021910]")
301
