IrcLog2009 03 04

17:08:02 * Jason_at_intel (n=[email protected]) has joined #scons 17:13:52 * garyo-home (n=[email protected]) has joined #scons 17:24:15 * GregNoel is no longer marked as being away 17:24:17 <GregNoel> Hi, Gary; I'm here, too; we can start as soon as Steven arrives 17:24:26 Hi, Greg. 17:25:03 <Jason_at_intel> hi all 17:25:09 Hi, Jason. 17:25:12 <GregNoel> I see you've been marking up the spreadsheet; good work. 17:25:25 Just barely in time :-) 17:25:45 <GregNoel> Better than trying to do it on the fly. 17:26:04 yup 17:32:04 <GregNoel> Where are you, Steven? 17:34:47 Since Steven's not here yet, Greg I'll ask you about 2357 and ListLike. Is that mostly like CLVar? 17:35:48 <GregNoel> Mostly, but the devil is in the details. I'm proposing that once you mark a variable as list-like, it can't be overridden by assignment. 17:36:14 That sounds cool, is it doable in python? 17:36:40 <GregNoel> (And I'm proposing a newCLVar class with slightly different semantics) 17:36:55 <GregNoel> Well, it's doable, but I don't yet know about fast. 17:37:24 <Jason_at_intel> Can i ask what teh point of CLVar is ? 17:37:36 I do like the env.ListLike(key) rather than env['KEY'] = CLVar() 17:38:22 <GregNoel> My thought was to make _dict a class rather than a dict, and then use property() to catch the assignments. 17:38:33 CLVar is a list that uses Split() to split an initial string along 17:38:35 white-space arguments, and similarly to split any strings that get 17:38:36 added. This allows us to Do the Right Thing with Append() and 17:38:38 Prepend() (as well as straight Python foo = env['VAR'] + 'arg1 17:38:39 arg2') regardless of whether a user adds a list or a string to a 17:38:41 command-line construction variable. 17:38:42 <GregNoel> I've mocked up something that almost works, but I haven't timed it. 17:39:11 Greg: I see, that sounds workable (not that I understand the details) 17:39:41 <GregNoel> Neither to I; that's why it almost works. {;-} 17:39:42 <Jason_at_intel> ahh.. I have been just using it as a list .. ie env['LINKFLAGS'].extend([stuff...]) 17:39:43 Greg: notice that CLVar already has quoting issues. Quoting rears its ugly head again! 17:40:28 <GregNoel> Yep, newCLVar is part of the SubstQuoteEscape, et.al., proposal 17:40:37 Jason: part of the problem is that not everything is a CLVar, and the other part as Greg said is that assigning to it kills the CLVarness. 17:40:43 Greg: good. 17:41:27 <Jason_at_intel> I see, will this require python 3.0 ( the need to use properties) 17:41:40 <GregNoel> 2.2 17:41:55 <Jason_at_intel> 2.2 has properties? 17:42:06 <GregNoel> yup 17:42:08 <Jason_at_intel> must have missed that 17:42:26 <Jason_at_intel> learn something new.. how do you say it? 17:42:37 doesn't Python have the assign function 17:42:54 or not 17:42:56 <GregNoel> sohail, not on variables 17:42:58 * sohail goes back to idling 17:43:22 Hi Sohail! 17:43:37 hi garyo-home ! 17:43:42 <GregNoel> Steven, where are you? 17:43:55 the $64,000 question. 17:43:59 * sohail is actually now being called to DINNER!!!!!!!! bbl 17:44:59 If Steven doesn't show up, should we just enter the consensus ones for now and reconvene later in the week? 17:48:00 <GregNoel> garyo-home, re Steven, yes, let's whip through what we can. 17:48:43 * GregNoel brb 17:48:43 Greg: yes, it's getting late, let's just accept the obvious ones. 17:49:06 <GregNoel> 1752 is first; brb 17:49:55 1752: not obvious, but everyone seems to say 2.x p3 stevenknight so that's it. 17:50:49 <GregNoel> (I'm back) done 17:51:06 2124: azverkan ok w/ you Greg? 17:51:08 <GregNoel> 2124: TaskmasterNG should make it easy to use worker threads for something like this, but it should be selectable, since it's not needed on a Real Operating System(TM) 17:51:32 worker threads may be faster in all cases though. 17:51:40 anyway, 2.x p3 azverkan? 17:51:46 <Jason_at_intel> what is the issue here? 17:52:02 <GregNoel> Yes, Brandon should be fine, although we should check with him, since he took so long to research it. 17:52:04 Jason: you'll have to read it, it's complicated. 17:52:22 race conditions. 17:52:22 <Jason_at_intel> ok.. have threading background ( to much of it) 17:52:40 you'll love reading the bug report then :-)( 17:52:55 ok, let's say 2124 is done then. 17:52:46 <GregNoel> 1594, 1849 consensus +java 17:53:03 greg: agreed. 17:53:25 1874: I'll document it, why not. 17:53:37 <GregNoel> done, more power to you 17:53:43 anytime p5 garyo 17:54:04 <GregNoel> 1905, I think it needs a higher priority if it's going in future. 17:54:10 1905: is StarMerge needed for your idea, or does it just make it better? 17:54:38 <GregNoel> I think it should be a separate issue (in fact, split in three) 17:54:47 If it's yours you can pick a priority. 17:54:56 <GregNoel> p2 then; done 17:55:26 1970: I don't have ideas on the keyword name yet 17:55:38 <GregNoel> 1970, I think we need Steven for this one 17:55:43 ok, leave it. 17:55:49 <GregNoel> next time it is 17:56:09 2153: steven 1.3/2.0/2.1 p2, pick one? 17:56:26 I presume he means try for 1.3, else ... 17:56:35 <Jason_at_intel> I think this is part of the VS revamp 17:56:44 <GregNoel> I like 2.1 or even 2.2, since 1.3 is already too full and 2.0 is just for the conversion 17:56:47 2153? I don't think so 17:56:55 Greg: agreed. 17:56:58 2.1 is fine. 17:57:02 <Jason_at_intel> it effect the mslink 17:57:07 <GregNoel> done 17:57:21 mslink uses it, but it's its own separate thing really. 17:57:42 <GregNoel> 2288, invalid, consensus 17:57:42 <Jason_at_intel> agreed on that.. I guess patches show it can be worked around 17:57:59 2288 invalid 17:58:23 <Jason_at_intel> 2288 is a misunderstand of what Install() does 17:58:23 <GregNoel> 2291, need Steven, since he's the 'compat' expert 17:58:55 2291: defer 17:59:02 <GregNoel> done 17:59:28 2351: Greg you're right it hasn't bit anyone that we know of, but still it's really wrong. 17:59:52 <Jason_at_intel> windows is case insentitive, but 17:59:58 <Jason_at_intel> case preserving 18:00:13 I think all it needs is a _dict that has the right semantics. 18:00:15 <GregNoel> True, but 2.x is very crowded; we have to start cutting some 18:00:19 <Jason_at_intel> if the case is lost certain programs can get upset 18:00:40 jason: right, preserve the case, just case-fold the comparisons. 18:00:58 Greg: I see your point. 18:01:20 Maybe you're right, 3.x is OK. 18:01:36 <GregNoel> I don't have a WAG about how much effort it would take, so I'm erring on the conservative side 18:01:36 Wish we had more devs. 18:01:59 <GregNoel> garyo-home, concur, more devs needed badly 18:01:56 A half a day here, half a day there adds up to a lot. 18:02:17 <GregNoel> "A million here, a million there..." 18:02:25 :-) 18:02:36 <GregNoel> Let's defer it 18:02:44 I'm ok w/ that 18:02:49 <GregNoel> done 18:03:00 <GregNoel> 2352, consensus 18:03:06 2352 1.3 p2 steven (+vs_revamp) 18:03:28 <Jason_at_intel> Steven is workign on it.. last he said he want to factor out if statements 18:03:32 <Jason_at_intel> talked about how to do it 18:03:36 <GregNoel> Good point, +vs_revamp 18:03:41 <Jason_at_intel> I think he has it under control 18:03:53 I'll be happy to help retest 18:03:58 2353 is really simple 18:04:08 <GregNoel> 2353, who? 18:04:33 me I guess. 18:04:46 <GregNoel> OK, if you're sure. 18:05:02 can't be hard, just need to get the time. 18:05:24 <GregNoel> "Ask me for anything except time..." 18:05:37 Nice quote, who's that from? 18:05:43 <GregNoel> 2.x or 2.1? 18:05:47 2.x. 18:05:51 <GregNoel> done 18:06:12 2354, +toolchain and defer? 18:06:44 <GregNoel> 2354, yes: I'll look up what the other toolchain issues are 18:06:53 <GregNoel> for milestone and priority 18:06:59 <Jason_at_intel> why assume it exists? 18:07:19 <GregNoel> 2355, defer 18:07:26 jason: are you talking about 2355? Yes, defer. 18:07:34 <Jason_at_intel> 54 18:07:41 <GregNoel> done 18:07:44 Sorry, 2354! 18:07:59 <GregNoel> 2356, consensus 18:08:06 <Jason_at_intel> yes ... 2355 was quick to resolve 18:08:36 2356 agreed. 18:08:46 <GregNoel> done 18:08:57 2357, Greg I think you're the man here. 18:09:22 <GregNoel> Yeah, I'm afraid so, but it needs a bit of discussion. Let's defer it. 18:09:26 ok. 18:11:55 <GregNoel> garyo-home, "anything except time" is Napoleon; missed the question above 18:12:10 cool. 18:10:01 2358: I like the +swig keyword, otherwise 2.1 p2 swig-expert 18:10:23 <GregNoel> 2358, +swig, but 2.1 would need a draft choice 18:10:41 (Might not actually require swig knowledge, just create the dir first or something) 18:10:44 ok, 2.x? 18:11:02 <GregNoel> We made the +java future p1; I think that's reasonable; pull them in when the expert shows up 18:11:51 usually I'd agree, but this issue may not really need a swig expert. 18:13:28 <GregNoel> I think it does require SWIG knowledge. The last patch I almost applied would have made a mess, but somebody showed up who knew that the .wrap.c file was created only if there was a certain option in the .i file 18:11:54 <Jason_at_intel> agreed.. the compiler can do different thing here 18:13:59 hmm, who was that? 18:14:29 <GregNoel> I was looking earlier; I've lost the name. 18:12:48 for instance, the swig builder could just get a "mkdir -p $OUTDIR" prepended. 18:13:06 I'm not volunteering, just saying it might work. 18:13:21 (sorry, $SWIGOUTDIR). 18:14:28 well anyway, I guess I'm ok with future p1 +swig. 18:15:00 <GregNoel> Your point is good; I'm changing my mind. 18:15:15 <GregNoel> Give it to me as research and I'll try harder to find the name. 18:15:24 ok, that works for me. 18:15:28 <GregNoel> done 18:15:49 <GregNoel> 2359, consensus, +java 18:15:56 yes 18:16:44 <GregNoel> 2361 also needs some research, but I don't think I'm the guy 18:16:44 2361: my temptation is do nothing and hope toolchain removes this issue. 18:17:12 <GregNoel> That could work, too, but when are we getting to the toolchain work? 18:17:00 let's defer that one for tonight. 18:17:18 <GregNoel> defer works for me 18:17:29 grumble... 18:17:40 ok defer for now. 18:17:48 <GregNoel> done 18:18:13 <GregNoel> 2362, wow, last one; it really helps to do the research in advance... 18:18:11 2362: I think Steven is the best one for that. 18:18:15 So let's defer it. 18:18:22 <GregNoel> done 18:18:38 ok, well done. 18:18:45 <GregNoel> agree 18:18:50 I'm guessing Steven forgot about us. 18:19:13 <GregNoel> maybe; he did update the spreadsheet. 18:19:25 <GregNoel> Let's contact him and see if we can resume tomorrow? 18:19:38 I think I can do that, especially if it's not too long. 18:19:53 I'll email him and cc release. 18:20:06 <GregNoel> Should be short; I think we deferred only five issues. 18:20:15 <GregNoel> works for me 18:20:19 <Jason_at_intel> ok 18:20:35 good. Hope to see you then. 18:20:59 <GregNoel> yep, see you then. I'm off to do some shopping for a party 18:21:13 have fun! 18:22:10 <GregNoel> It ought to be; it's a surprise anniversary party; over 50 people from all over the country are attending, unknown to the victims 18:22:31 * GregNoel has been marked as being away 18:22:49 Greg: wow, sounds amazing. 18:23:04 <Jason_at_intel> hope the paty goes well 18:25:57 * stevenknight (n=[email protected]) has joined #scons 18:26:07 anyone still here? 18:26:41 Hi Steven! 18:26:42 <Jason_at_intel> yep.. we are still here .. greg might have left 18:26:45 hey 18:26:54 see my email just now? 18:27:05 sorry for not being here, the wife has a migraine today 18:27:13 no, haven't checked email yet 18:27:19 ouch, they are really awful. 18:27:34 My daughter gets them once in a while. 18:27:35 <Jason_at_intel> ya... my wife gets them... I understand 18:27:38 i had to pick up the afternoon duties 18:27:46 child pick up, etc. 18:27:57 understood. Can we finish up the bug party tomorrow night at the usual time? 18:28:06 that should work 18:28:07 <GregNoel> Wait, 18:28:12 hey greg 18:28:16 at least for me 18:28:36 <GregNoel> Hi, just happened to be passing through the office to grab something and saw you had arrived. 18:29:03 yeah, family matters intervened; sorry 18:29:49 <GregNoel> It's OK; I can stay a few more minutes, but I need to leave shortly. I didn't keep a list of the issues we bypassed; did you, Gary? 18:30:18 Greg: no, but we can find them quickly I think. 18:31:17 <GregNoel> 1970? 18:31:58 My defer list from the irc log: 2291, 2351, 2354, 2355, 2357, 2361, 2362 18:32:28 <GregNoel> 2291, then 18:32:34 <Jason_at_intel> 2352? 18:32:39 oh yes, 1970 too. 18:32:57 <GregNoel> More than I thought... 18:33:15 no 2352 is done. 18:33:28 I can do a few now. 18:33:36 How about 1970 as you suggested. 18:34:08 it needs a keyword. 18:34:44 <GregNoel> getting_started seems too long 18:35:07 newbie not very flattering 18:35:22 easy_contribution too long 18:35:30 <GregNoel> small seems diminutive {;-} 18:35:45 "initial" 18:35:49 nah 18:35:59 "starter" 18:36:01 <GregNoel> starter? startup? initial isn't bad 18:36:07 <GregNoel> jinx 18:36:05 actually I kind of like "small". It's nonthreatening. 18:36:08 Or starter. 18:36:26 "easy" ... 18:36:34 <GregNoel> Oooohhhh, yes 18:36:43 yes, that's good. 18:36:48 +easy 18:36:57 <GregNoel> done; now about the issue? 18:37:53 what about it? 18:38:12 <GregNoel> anytime and draft pick don't fit together 18:38:48 I think anytime and +easy shouldn't need an owner. 18:38:52 <Jason_at_intel> just read..2124... have feedback on it if you want it ( it is not install()) 18:39:14 agree w/gary 18:39:19 <GregNoel> it needs a schedule, so we're forced to pick someone, or a person, so they can plan it themselves 18:39:27 for tracking purposes, create a "draftpick" user? 18:39:49 <GregNoel> uh. issues@scons? 18:39:42 if it needs a schedule, is it really "anytime?" 18:40:06 <GregNoel> that's my point 18:40:08 any placeholder is ok w/ me for this type. 18:40:42 <GregNoel> I don't like it, but I'll go with anytime+easy and we'll see how it works. Contact Jean anyway. 18:40:47 GregNoel: i'm not following you 18:40:55 Jason: you're right 2124 is not Install, it's an OS handle inheritance race condition. 18:41:05 <Jason_at_intel> it is not the OS 18:41:20 <Jason_at_intel> we had it out with MS on this... it something else 18:41:39 <Jason_at_intel> we have this problem as of today with something completely different 18:41:41 ? If you have info, please add it to the ticket. Of course we want to hear about it too. 18:41:54 <Jason_at_intel> sure 18:41:59 <GregNoel> my point is that if you just say "anytime" and don't assign someone, it will simply keep floating out into the future 18:42:16 Greg: isn't that the point? 18:42:20 right, and isn't that precisely what we're trying to do? 18:42:29 have a pool of "easy" issues that don't have names assigned 18:42:39 as an encouragement for others to get involved? 18:42:48 <GregNoel> If that's what you want, I'll go with it. 18:43:02 okay, let's go with that and see how it works 18:43:19 if it ends up with some unforeseen downside, we can adjust 18:43:15 <GregNoel> 2291? 18:45:51 Steven, 2291 needs your comments. 18:46:08 <GregNoel> 2291, my point is that we probably can't do a compat module without adding C code 18:46:42 Greg: good point. 18:47:43 is ctypes => types like cProfile => profile? 18:48:02 <GregNoel> I don't think so 18:48:20 <Jason_at_intel> I thought ctypes was a way to call a C functions in a DLL or .so 18:48:20 no, ctypes is C types wrapped for python. 18:48:25 ah 18:48:41 <GregNoel> plus calling sequences 18:48:58 <GregNoel> so you can wrap a function call with fairly arbitrary arguments 18:49:11 right, all that stuff. It's very general & useful 18:49:10 okay, the C implementation necessity probably suggests it's not a good compat candidate 18:49:17 but I'm flying a little blind here (obviously) 18:49:28 right, couldn't make a compat version of it. 18:49:31 no way. 18:49:56 <GregNoel> http://docs.python.org/library/ctypes.html 18:50:07 <Jason_at_intel> I am confused... to use ctypes you have to make a c binary? 18:50:39 Jason: by "compat" we mean could we emulate it in older python versions? 18:51:17 For 2291 I think we should do nothing. 18:51:20 <GregNoel> I assume we'd want to make this change eventually, but not until 2.5 is the floor, since that's where ctypes becomes standard 18:51:19 <Jason_at_intel> oh.. I agree fully with that.. you would have to add the Ctype as a extra to the install 18:51:28 <Jason_at_intel> much like Ipython did 18:51:40 Greg: agreed. 18:51:47 <GregNoel> So where do you want to put it? Future p1? 18:51:59 Seems reasonable. 18:52:31 <GregNoel> Maybe with a keyword of something like floor2.5? 18:52:37 future p1 sounds good 18:52:44 hmm, just looking at the patch 18:52:53 I was just thinking that (keyword floor2.5) 18:53:01 to do a compat implementation we don't have to support absolutely everything 18:53:17 in some cases we intentionally support only enough to emulate what we use 18:53:20 <GregNoel> All it takes is one 18:53:37 <GregNoel> C file, that is 18:53:55 so the key question: is there anything in the patch that's not tractable in pure Python? 18:54:00 ... such as ctypes.cdll.msvcrt._get_osfhandle. 18:54:04 <Jason_at_intel> is there any hope to support iron python? 18:54:15 <Jason_at_intel> Will Ctypes work there? 18:54:30 good question re: iron python 18:54:47 i'd actually really like it if we'd run under iron python and jython 18:55:33 side issue. For 2291 can we say future p1 +floor2.5? 18:55:44 <GregNoel> I'll go for that 18:56:24 <GregNoel> Steven? 18:56:32 concur 18:56:36 still looking at code 18:56:57 <GregNoel> done, and I'll make it depend on 2124 18:56:50 this is contained enough that I think we can do it with a compat layer 18:57:16 <GregNoel> If so, we can review it again 18:57:32 okay 18:57:57 <GregNoel> 2353, yes? 18:58:08 2351: 2.x or 3.x? Greg is worried (correctly) that 2.x is crowded 18:58:36 so minor things like this should be pushed to 3.x. 18:58:39 <GregNoel> oops, yes, 2251; skipped one 18:58:38 Steven? 18:59:05 <GregNoel> or 2.x p4 or p5 18:59:28 you mean 2351 i hope? I don't see 2251 on the list 18:59:33 yes 2351 18:59:47 <GregNoel> 2351 19:00:06 * GregNoel isn't doing any mondo typing tonight... 18:59:49 i'd prefer 2.x, especially if it's going to be p5 anyway 18:59:59 yes, it's crowded 19:00:23 but i'd at least like to consider it in the 2.x time frame 19:00:38 and make a conscious decision to push it farther out when we (re-)categorize all the 2.x issues 19:00:41 <GregNoel> 2.x p4 or p5 is fine with me 19:00:50 <GregNoel> yes, I agree 19:00:54 okay, 2.x p4 then 19:00:56 ok too. 19:00:59 <GregNoel> done 19:01:13 <GregNoel> 2353 19:02:00 2353: +easy? 19:02:09 eh, it's a patch... 19:02:24 is the question who? 19:02:41 I thought I volunteered for 2353. 19:02:46 <GregNoel> Wait, didn't you take this one, Gary? 2.x p2? 19:03:01 Next on my list was 2354. 19:03:16 2354: consensus +toolchain 19:03:42 ok, right. 19:03:48 <GregNoel> Ah, I'm blind, it's 2355 19:03:47 2355 then. 19:04:03 k 19:04:16 2355 is -j vs. chdir 19:04:47 decision point: do we just doc the limitation (as suggested by the issue) 19:05:01 and open another one for greg's SideEffect() suggestion? 19:04:50 <Jason_at_intel> I would like a warning 19:05:29 Jason_at_intel: agree, a warning in this case would be good, too 19:06:10 <Jason_at_intel> If you don't warn people will think SCons is broken with -j.. even if it is not SCon's fault 19:06:41 <GregNoel> The SideEffect() needs some research, but a separate issue is a good idea 19:07:09 <GregNoel> Let's make 2355 cause a warning; make a new one for SideEffect() 19:07:27 ok, so make the current issue 2.x p4 stevenknight, and a new issue for the SideEffect idea? 19:07:39 <GregNoel> done 19:08:10 I think 2357 is next 19:08:31 <GregNoel> Yeah. I need to explain ListLike() again... 19:09:01 (We were just going to assign this to Greg but it needs discussion first.) 19:09:02 <GregNoel> The idea is that marking a variable as list-like means that it survives even assignment 19:09:46 ? 19:10:03 you mean even if I did env['CCFLAGS'] = 'foo' 19:10:14 <GregNoel> yep 19:10:25 an original ListLike value of CCFLAGS would not be overwritten? 19:10:54 <Jason_at_intel> that would require a env.Replace() ? 19:10:57 <GregNoel> it would be reset to ['foo'] but it's still list-like 19:11:20 wait, i think i get it 19:11:33 it's marking certain variables as always being treated as lists 19:11:57 so that the "list like" behavior is a function of its semantic meaning in the environment 19:12:06 not of the fact that its value is a specific object 19:12:02 <GregNoel> yes, exactly, it's mentioned in the Subst... page, but not detailed 19:12:26 agree conceptually 19:12:45 <Jason_at_intel> is there a prototype of this code? 19:12:46 different variables actually do have different semantics 19:12:52 based on what they "mean" 19:12:55 <GregNoel> yes 19:13:12 being smarter about that strikes me as a Good Thing 19:13:19 <GregNoel> yes 19:13:28 <Jason_at_intel> where? and can i give it a test run for you 19:13:39 <GregNoel> it also makes the tokenizing, usw., work better 19:13:33 but also potentially dangerous if we don't define things carefully 19:13:54 <GregNoel> yes, potentially dangerous 19:14:01 <GregNoel> as are all good tools 19:14:26 <Jason_at_intel> risk is what makes life fun :-) 19:15:23 i could do with a little less fun lately... :-) 19:15:27 Greg, can you prototype it? 19:16:21 <GregNoel> I have a very rough prototype that works most of the time, but I'm still trying to figure out why it's only "most". 19:17:01 <Jason_at_intel> glad to look at it .. if you can share it 19:17:10 That seems like a good next step. 19:17:16 <GregNoel> In my copious spare time, I can try to prepare something to show how it works, but the basic idea is simple: 19:17:43 <GregNoel> convert env.dict[key] into env.vars.key 19:18:16 <GregNoel> then property() will Do The Right Thing 19:18:57 in that case key has to be a python identifier, but perhaps that's already the case. 19:19:04 <GregNoel> yes 19:19:43 <GregNoel> [a-zA-Z]\w* to be precise 19:20:31 <GregNoel> In any event, we're spending too much time on this 19:20:54 yes, send it around, but for now let's move on. 19:20:58 <GregNoel> We should either defer it or try to figure out what the next step is 19:21:12 research, greg. 19:21:16 <GregNoel> works 19:21:29 +1 19:21:43 I think 2361 is next? 19:21:46 <GregNoel> 2361 19:22:31 <GregNoel> I think it needs some research to see exactly what he thought he was trying to do, but I don't think I'm the guy 19:22:38 Greg & I are hoping toolchain rework will eliminate this one 19:23:04 yep 19:23:16 <GregNoel> true, but I'd like to know what he thought he was doing 19:23:20 but it would be good to document the restrictions in the meantime 19:23:24 <GregNoel> yes 19:23:32 he just happens to be using a variable he named "options" 19:23:51 I think you're right, and we reserve that name. 19:24:00 <GregNoel> I think so, but I'd like to be sure 19:24:04 ...without telling anyone... :-( 19:24:08 agree re: being sure 19:24:34 There's a lot about Tools that is imperfectly documented right now. I'm not even sure this is where to start. 19:24:34 i'll take it if no one else wants it 19:24:48 and ask him for a copy of his module 19:24:53 ok, thanks 19:25:11 <GregNoel> OK, but don't spend any significant time on it; he may be able to just tell you 19:25:21 agreed 19:25:27 yes 19:25:37 <GregNoel> last one, 2362 19:25:50 +easy 19:26:20 <GregNoel> hmmmm 19:27:12 Steven, I was hoping you'd take that one. 19:27:20 <GregNoel> I'll agree to marking it easy, but let's put it in the queue to get done 19:27:40 2.x p4 stevenknight +easy? ??? 19:27:43 <GregNoel> 2.x p4 is fine with me 19:27:53 hey, i'm easy but i'm not cheap 19:27:58 :-) 19:27:59 <GregNoel> {;-} 19:28:14 2.x p4 stevenknight is fine w/me 19:28:22 <GregNoel> OK, done 19:28:23 ok, great. We did them all! 19:28:34 wow, nice work 19:28:40 It's late here on the early coast. 19:28:41 and special thanks for hanging out late after i showed up 19:28:45 <GregNoel> Yes, and now I've got 30 mins to do the shopping.... 19:28:51 <GregNoel> bye, cul 19:28:53 ok, bye all. 19:29:02 * garyo-home has quit ("ChatZilla 0.9.84 [Firefox 3.0.6/2009011913]") 20:57:34 * stevenknight has quit ("This computer has gone to sleep")