IrcLog2008 06 17

17:00:52  <[GregoryNoel](GregoryNoel)>  It's time.  Who's where for the bug party? 
17:01:24  *      garyo-home (n=[[email protected]](mailto:[email protected])) has joined #scons 
17:01:47  <garyo-home>   Hi folks. 
17:01:57  <[GregoryNoel](GregoryNoel)>  Folk, singular. 
17:02:17  <garyo-home>   Hi, Greg. 
17:02:39  <[GregoryNoel](GregoryNoel)>  Hi...  Nobody here but me and thee. 
17:02:52  <garyo-home>   ok, let's wait a bit then. 
17:03:05  <[GregoryNoel](GregoryNoel)>  yup 
17:03:28  <[GregoryNoel](GregoryNoel)>  I notice you haven't marked up the current issues.  Nothing to say? 
17:03:43  <garyo-home>   I assume Steven's on his way, he did the spreadsheet etc. 
17:04:20  <garyo-home>   re: current issues: no, I missed them :-(, did all the old ones. 
17:04:46  <[GregoryNoel](GregoryNoel)>  yes, he did, but basically only he and I marked them up. 
17:05:15  <garyo-home>   I did a bunch of old ones actually. 
17:05:20  *      [GregoryNoel](GregoryNoel) overrun by puppy, hang on 
17:05:34  <garyo-home>   Grr, current spreadsheet isn't letting me in yet... 
17:06:14  *      garyo-home has quit (Client Quit) 
17:07:10  *      garyo-home (n=[[email protected]](mailto:[email protected])) has joined #scons 
17:07:13  *      david<ins> (n=[[email protected]](mailto:[email protected])) has joined #scons 
17:07:37  <[GregoryNoel](GregoryNoel)>  Ho, David; welcome back, Gary 
17:07:44  <garyo-home>   Hi again guys. 
17:08:00  <garyo-home>   I still can't write the current issue spreadsheet but I guess it's too late anyway :-( 
17:08:10  <david</ins>>      hello everyone 
17:08:34  <[GregoryNoel](GregoryNoel)>  It worked fine for me; why do you keep having problems? 
17:08:19  <david<ins>>      Am i late ? 
17:08:39  <garyo-home>   no, we're waiting to see who else shows up, hopefully Steven. 
17:08:55  <garyo-home>   Greg: bad behavior in previous life perhaps? 
17:09:13  <[GregoryNoel](GregoryNoel)>  Must be.  Or maybe you're overthinking it. 
17:09:10  <garyo-home>   Maybe Firefox issue? 
17:09:30  <[GregoryNoel](GregoryNoel)>  Not Firefox; works for me. 
17:09:33  <garyo-home>   Some of them work no prob, others dont. 
17:09:44  <garyo-home>   Individual invites have always worked. 
17:10:02  <david</ins>>      does anyone else have slowness problems with spreadsheet ? They are not usable for me, keeps taking 100 %. I have to use another computer for it :) 
17:10:19  <garyo-home>   No, they're usually fine foe me. 
17:10:19  <[GregoryNoel](GregoryNoel)>  They're not fast, but one copes. 
17:10:53  <[GregoryNoel](GregoryNoel)>  david<ins>, do you use Firefox? 
17:10:58  <david</ins>>      Yes 
17:11:13  <[GregoryNoel](GregoryNoel)>  2.0.0.whatever? 
17:11:23  <david<ins>>      firefox 2. something. Other people had problems with it on ubuntu 
17:11:34  <david</ins>>      With spreadsheet, I mean.  
17:11:53  <[GregoryNoel](GregoryNoel)>  Hmmm...  Works fine on my Mac. 
17:12:14  <garyo-home>   I'm using ffox 2.0 on win xp.  I'll try Ubuntu sometime. 
17:12:16  <[GregoryNoel](GregoryNoel)>  Maybe you should get yourself a new computer {;-} 
17:12:28  <[GregoryNoel](GregoryNoel)>  Both of you... 
17:12:30  <david<ins>>      It's a bi-cpu, pentium 4 
17:12:32  <garyo-home>   ... or a new OS 
17:12:54  <garyo-home>   my hw is fine, fast core 2 duo, 2gb etc. 
17:13:01  <david</ins>>      While p4 are not great, they should make possible to read spreadsheet which look simpler than the ones on excel 95 
17:13:41  <garyo-home>   david<ins>, you're right. 
17:13:46  <[GregoryNoel](GregoryNoel)>  Humpf.  PPC 1Ghz rules. 
17:13:43  <david</ins>>      I think there is a bad interaction between ubuntu themes, my hardware and firefox. 
17:14:30  <david<ins>>      So how does this work ? I've just commented on the things I thought I knew something about in the current issues spreadsheet 
17:15:16  <[GregoryNoel](GregoryNoel)>  We work through the issues and decide where they should go (which milestone and priority) 
17:15:54  <david</ins>>      Which spreadsheets are used, besides the current issues one ? 
17:16:10  <[GregoryNoel](GregoryNoel)>  The next one not ticked off 
17:16:12  <garyo-home>   HA - I can open the spreadsheet just fine (r/w) on Ubuntu Hardy in a VM. 
17:16:26  <[GregoryNoel](GregoryNoel)>  with luck, the one after that 
17:16:36  <[GregoryNoel](GregoryNoel)>  and maybe the one after that. 
17:16:59  <garyo-home>   OK, maybe Steven's not coming? 
17:17:01  <david<ins>>      @gary: yes, that's the strange thing, it works better in vm on my another computer 
17:17:22  <garyo-home>   Should we just start and see what we can do? 
17:17:30  <[GregoryNoel](GregoryNoel)>  I'm ready 
17:17:43  <[GregoryNoel](GregoryNoel)>  1643? 
17:17:58  <[GregoryNoel](GregoryNoel)>  Has anyone been in contact with Brandon? 
17:18:03  <garyo-home>   not me. 
17:18:27  <garyo-home>   pass back to OP for more info? 
17:18:45  <[GregoryNoel](GregoryNoel)>  I'm really hesitant to pass over this again, but I don't see any other course. 
17:18:58  <[GregoryNoel](GregoryNoel)>  I don't think the OP has any more info. 
17:19:11  <garyo-home>   How about ask him for the config log. 
17:19:51  <[GregoryNoel](GregoryNoel)>  huh.  Somebody named "sharing" just opened the spreadsheet.  Is that you, David? 
17:19:57  <garyo-home>   Or whether it's all in the same run or separate runs.  And to please post the SConstruct. 
17:20:30  <[GregoryNoel](GregoryNoel)>  OK, but not me, I'm on holiday.  Can you take it? 
17:20:38  <garyo-home>   Sure. 
17:20:51  <[GregoryNoel](GregoryNoel)>  garyo, research, done 
17:21:01  <[GregoryNoel](GregoryNoel)>  1675? 
17:21:05  <david</ins>>      I don't know if sharing is me. Maybe it is, I can't connect to gmail, so I am read only... 
17:21:38  <garyo-home>   1675: wine bug, close. 
17:21:52  <[GregoryNoel](GregoryNoel)>  done 
17:22:01  <[GregoryNoel](GregoryNoel)>  2089 
17:22:39  <[GregoryNoel](GregoryNoel)>  I think the two-variable solution is the right course, but when? 
17:22:48  <garyo-home>   enhancement req: 2.x p3 
17:22:59  <[GregoryNoel](GregoryNoel)>  Hmmm....  OK 
17:23:13  <[GregoryNoel](GregoryNoel)>  wait, 2.x?  Not 1.x? 
17:23:20  <garyo-home>   I could go with that. 
17:23:41  <garyo-home>   It's supposed to be really simple, right?  Just pass the flag to compiler? 
17:23:44  <[GregoryNoel](GregoryNoel)>  I think it needs to be sooner rather than later, and it doesn't look that complex. 
17:23:49  <garyo-home>   ok, 1.x. 
17:23:54  <[GregoryNoel](GregoryNoel)>  Two flags, yeah. 
17:24:09  <[GregoryNoel](GregoryNoel)>  p3? 
17:24:30  <garyo-home>   that's my default 
17:24:39  <[GregoryNoel](GregoryNoel)>  OK, for Steven? 
17:24:49  <garyo-home>   yes 
17:24:54  <[GregoryNoel](GregoryNoel)>  1.x, p3, steven, done 
17:25:01  <[GregoryNoel](GregoryNoel)>  2095? 
17:25:43  <[GregoryNoel](GregoryNoel)>  1.x+symlink, p4, me 
17:25:57  <garyo-home>   Right, I think your ssheet comment is good. 
17:26:20  <[GregoryNoel](GregoryNoel)>  It's how I'd expect it to work {;-} 
17:27:01  <[GregoryNoel](GregoryNoel)>  no other comments?  Done then? 
17:27:18  <david<ins>>      I don't understand the issue, never use symlinks in builds :) 
17:27:20  <garyo-home>   ok. 
17:27:31  <[GregoryNoel](GregoryNoel)>  done 
17:27:36  <[GregoryNoel](GregoryNoel)>  2096? 
17:27:40  <garyo-home>   david</ins>: not sure we'll ever handle them 100% perfectly, but we can do better. 
17:27:54  <garyo-home>   2096: research. 
17:28:06  <[GregoryNoel](GregoryNoel)>  I'm game 
17:28:08  <david<ins>>      Is it something scons is supposed to support or not ? 
17:28:19  <[GregoryNoel](GregoryNoel)>  Good question. 
17:28:27  <[GregoryNoel](GregoryNoel)>  It should support it, but how? 
17:28:50  <[GregoryNoel](GregoryNoel)>  Should all configuration be global?  Or should all configuration be local? 
17:28:34  <garyo-home>   Each one independently, yes.  Together: probably should, just haven't thought it through. 
17:28:57  <[GregoryNoel](GregoryNoel)>  Or some combination of both? 
17:29:04  <[GregoryNoel](GregoryNoel)>  It's not obvious. 
17:29:06  <david</ins>>      gary: maybe [VariantDir](VariantDir) is not the right way, but I think scons should support the notion of a self contained build directory for everything scons ever spits out 
17:29:08  <garyo-home>   Actually now that you mention it, I use both, and expect the sconf files to be under root, not in the build dir.  But I do all my sconf from the SConstruct. 
17:29:42  <[GregoryNoel](GregoryNoel)>  That's why I posed the question 
17:29:40  <garyo-home>   david<ins>: you can use --srcdir for that.  mkdir build; cd build; scons --srcdir .. 
17:30:13  <garyo-home>   anyway, we shouldn't design it here & now. 
17:30:19  <garyo-home>   research, steven. 
17:30:26  <[GregoryNoel](GregoryNoel)>  True...  agree 
17:30:41  <david</ins>>      ok. 
17:30:39  <[GregoryNoel](GregoryNoel)>  2097? 
17:30:59  <david<ins>>      The problem of 2097 is different than 2096, I believe 
17:31:06  <david</ins>>      but if we don't support 2096, then... 
17:31:13  <[GregoryNoel](GregoryNoel)>  Question here is whether this ends up the same issue as 2096 
17:31:20  <david<ins>>      The problem is in [TryRun](TryRun) 
17:31:45  <david</ins>>      Building and linking works fine, but the run the target is not aware of [BuildDir](BuildDir) 
17:31:53  <[GregoryNoel](GregoryNoel)>  But [TryRun](TryRun) is part of SConf, and it should figure out where things should go. 
17:32:03  <garyo-home>   2097 doesn't say anything about [TryRun](TryRun) ?? 
17:32:32  <[GregoryNoel](GregoryNoel)>  In the description, I think 
17:33:02  <david<ins>>      Argh, you're right gary, sorry, I mixed up things 
17:33:02  <[GregoryNoel](GregoryNoel)>  Both are about where the build tests are made and where the results go 
17:33:13  <garyo-home>   huh?  2097 = scons is confused when configuration checks are put into build dir set by [VariantDir](VariantDir)  ? 
17:33:28  <david</ins>>      The problem of 2097 is with the sconsign file 
17:33:35  <garyo-home>   david<ins>: right. 
17:33:40  <david</ins>>      when sconsign is put into the build-dir 
17:34:04  <garyo-home>   david<ins>: actually, when it's *not* in the build dir things can get confused. 
17:34:35  <david</ins>>      Well, in that case, when build dir is not used, it works as expected ? What do you mean ? 
17:34:43  <garyo-home>   but I agree it should check that the files still exist before thinking the file is uptodate. 
17:35:14  <garyo-home>   no, I mean I usually put the .sconsign file into the build dir.  Then removing the build dir removes the .sconsign file and I don't have this problem. 
17:35:31  <david<ins>>      ah 
17:35:48  <garyo-home>   Anyway, it is a bug I think; scons should not think a nonexistent file is up to date! 
17:35:53  <david</ins>>      yes 
17:36:14  <[GregoryNoel](GregoryNoel)>  so, research, steven? 
17:36:15  <garyo-home>   1.x p3 IMHO; who should get configure things? 
17:36:23  <garyo-home>   steven I guess 
17:36:49  <[GregoryNoel](GregoryNoel)>  I think these two should be kept as a pair and assigned the same place 
17:36:52  <david<ins>>      how do you decide between 1.x and 2.x ? 
17:37:01  <[GregoryNoel](GregoryNoel)>  WAG 
17:37:10  <garyo-home>   :-) 
17:37:18  <david</ins>>      WAG meaning ? 
17:37:32  <[GregoryNoel](GregoryNoel)>  Oh, sorry, that's an anagram of "wild-ass guess" 
17:37:33  <garyo-home>   1.0: severe bug.  1.x: should be fixed soon, or hi pri enh req.  2.x: everything else. 
17:37:45  <garyo-home>   how's that? 
17:37:48  <david<ins>>      ok, one new acronym for me 
17:38:01  <[GregoryNoel](GregoryNoel)>  yes, acronym 
17:38:17  <garyo-home>   I don't think 2096 and 2097 are the same; they can be assigned differently. 
17:38:28  <[GregoryNoel](GregoryNoel)>  You forgot 1.0.x and future. 
17:39:11  <garyo-home>   I don't know what to say about 1.0.x; future is so we don't lose track of cool ideas that are not currently practical. 
17:39:29  <david</ins>>      I think 2097 is more sever than 2096, no ? 
17:39:40  <david<ins>>      2096 just does not work. But 2097 is quite surprising 
17:39:44  <garyo-home>   david</ins>: and probably easier to fix. 
17:39:55  <garyo-home>   (2097 easier than 2096) 
17:40:05  <david<ins>>      yes 
17:40:05  <[GregoryNoel](GregoryNoel)>  Both have to do with location of files 
17:40:20  <[GregoryNoel](GregoryNoel)>  I'll bet if you fix one, the other is 90% done 
17:40:41  <garyo-home>   If you fix 2096, 2097 might go away, but not the other way round. 
17:40:55  <garyo-home>   anyway, how about a note in each one referring to the other. 
17:41:00  <[GregoryNoel](GregoryNoel)>  works 
17:41:20  <david</ins>>      I don't understand the implications enough, so nothing to say 
17:41:26  <[GregoryNoel](GregoryNoel)>  so you wanted 1.x p3: I'll go for that 
17:41:33  <david<ins>>      sorry, I meant for issues 2096-2097 
17:41:56  <garyo-home>   Greg: 2097 1.x p3? yes. 
17:42:04  <[GregoryNoel](GregoryNoel)>  done 
17:41:18  <garyo-home>   2098: has patch, good! 
17:42:23  <[GregoryNoel](GregoryNoel)>  2098, I'm not sure the patch will fly as is 
17:42:40  <garyo-home>   haven't looked at it. 
17:42:57  <[GregoryNoel](GregoryNoel)>  It's too simple; special case for python and java, nothing else 
17:43:19  <[GregoryNoel](GregoryNoel)>  so if you had -python -tcl as parameters, it would fail. 
17:43:33  <garyo-home>   I see.  OK, so pass back to OP with comments? 
17:43:40  <[GregoryNoel](GregoryNoel)>  I mean SCons would fail, since it wouldn't get the output right. 
17:43:56  <garyo-home>   Right, understood. 
17:43:58  <[GregoryNoel](GregoryNoel)>  Hmmm...  Sure, we can try that; review next week? 
17:44:05  <garyo-home>   Ask OP to improve patch and resubmit. 
17:44:10  <[GregoryNoel](GregoryNoel)>  done 
17:44:14  <garyo-home>   I'll do it. 
17:44:43  <[GregoryNoel](GregoryNoel)>  somebody will have to do most of them; I won't be around 
17:45:15  <garyo-home>   OK, if you email me the irc log I'll do the data entry. 
17:45:41  <[GregoryNoel](GregoryNoel)>  I can set up the IRC page; I have the tools, but that will be pretty much it. 
17:46:24  <garyo-home>   ok, that's fine.  I'll look there. 
17:46:31  <[GregoryNoel](GregoryNoel)>  2100? 
17:46:37  <garyo-home>   I may have logging enabled here too.  OK, 2100... 
17:47:18  <garyo-home>   Saw this on the ML.  Steven understands it.  I think should be fixed soon; it's a regression. 
17:47:29  <[GregoryNoel](GregoryNoel)>  I don't agree. 
17:47:37  <garyo-home>   ok? 
17:47:37  <david</ins>>      How supporting # in LIBS makes linking more platform independant ? 
17:47:55  <[GregoryNoel](GregoryNoel)>  Not a platform-dependent issue. 
17:47:57  <garyo-home>   umm.  never mind, I was looking at 2099.  Sorry. 
17:48:16  <[GregoryNoel](GregoryNoel)>  Ah, we skipped one... 
17:48:21  <[GregoryNoel](GregoryNoel)>  2099! 
17:48:34  <david<ins>>      The comment of 2100 says it would make it easier to support platform independant linking, so I guess I am missing something 
17:48:56  <garyo-home>   ok, 2099 I say 1.0 or 1.0.x, p2.  Regression. 
17:49:04  <[GregoryNoel](GregoryNoel)>  Let's finish 2100 and then go back 
17:49:10  <garyo-home>   ok 
17:49:26  *      stevenknight (n=stevenkn@nat/google/x-bf5612cd2f2152ca) has joined #scons 
17:49:34  <stevenknight> hey, anyone still here? 
17:49:38  <garyo-home>   Hi, Steven! 
17:49:42  <[GregoryNoel](GregoryNoel)>  No, we've all left 
17:49:58  <[GregoryNoel](GregoryNoel)>  We're arguing over 2100 
17:50:15  <stevenknight> sorry about that, got pulled into one of those urgent impromptu meetings 
17:50:15  <garyo-home>   2100: if it's a pathname, why not use ./#foo.so if the libname is foo and you don't want it turned into top-relative? 
17:50:35  <garyo-home>   steven: we just gave you all the bugs, p1, 1.0. 
17:50:39  <[GregoryNoel](GregoryNoel)>  It's _not_ a pathname! 
17:50:42  <stevenknight> excellent 
17:50:44  <garyo-home>   ;-) 
17:50:54  <[GregoryNoel](GregoryNoel)>  It's a library name. 
17:51:04  <garyo-home>   He says path name. 
17:51:15  <stevenknight> historically, it's been a library name 
17:51:27  <[GregoryNoel](GregoryNoel)>  If you put a bare string in LIBS, it gets wrapped. 
17:51:28  <stevenknight> my question is:  is there a reason why it can't also refer to an actual *library*? 
17:51:33  <stevenknight> either as a node or a path name? 
17:51:52  <[GregoryNoel](GregoryNoel)>  How can you tell?  Library names can be anything, including 'm' 
17:52:03  <garyo-home>   I use Nodes, but I think abs pathnames work too.  Maybe # is turning it *into* a pathname? 
17:52:20  <garyo-home>   Greg: begins with / or is a Node. 
17:52:33  <stevenknight> garyo-home:  Nodes in LIBS, or Nodes in the SOURCES list? 
17:52:38  <[GregoryNoel](GregoryNoel)>  I can't check quickly, but I'm not sure I believe it. 
17:52:40  <garyo-home>   LIBS. 
17:52:56  <garyo-home>   I know Nodes work, not sure about abs paths. 
17:53:01  <[GregoryNoel](GregoryNoel)>  And what if it begins C: ? 
17:53:09  <stevenknight> I don't think abs paths work 
17:53:18  <[GregoryNoel](GregoryNoel)>  I don't either 
17:53:19  <stevenknight> I think strings all just get a -l prepended (on Linux) 
17:53:20  <garyo-home>   ok, I defer to you. 
17:53:36  <garyo-home>   In which case what's the bug? 
17:53:44  <[GregoryNoel](GregoryNoel)>  invalid 
17:54:04  <stevenknight> You can say env.Program('#foo.c', LIBS=['#bar.lib']) 
17:54:16  <stevenknight> and the target gets interpreted into a Node 
17:54:18  <stevenknight> and the LIBS doesn't 
17:54:23  <[GregoryNoel](GregoryNoel)>  and the first is a file and the second is the name of a lib 
17:54:26  <stevenknight> and that looks inconsistent to users 
17:54:40  <garyo-home>   Steven: but File('#bar.lib') does.  I think it's correct as is. 
17:54:42  <stevenknight> if it's only for the name of a lib then why can you use a Node therE? 
17:55:09  <garyo-home>   sorry, you have to know the path to use File(...) so it's not as easy as I said above. 
17:55:19  <stevenknight> exactly 
17:55:23  <garyo-home>   So you have a point. 
17:55:38  <[GregoryNoel](GregoryNoel)>  Why doesn't File(#name) work? 
17:55:52  <stevenknight> it does 
17:55:53  <garyo-home>   Greg: because typically name is in LIBPATH, not here. 
17:56:02  <stevenknight> but why do you have to specify File() for the target and not the LIBS? 
17:56:19  <[GregoryNoel](GregoryNoel)>  because it's a library name 
17:56:29  <stevenknight> then why does a Node work there? 
17:56:45  <garyo-home>   special dispensation, escape hatch. 
17:56:47  <stevenknight> okay, ta,e this out of LIBS 
17:56:51  <[GregoryNoel](GregoryNoel)>  There's a programing language with sharp in the name; I can believe a library name that starts with a sharp 
17:57:19  <stevenknight> should this behave the same as CPPPATH? 
17:57:34  <garyo-home>   Does it? 
17:57:43  <stevenknight> i'm not sure, actually  :-) 
17:58:01  <[GregoryNoel](GregoryNoel)>  if it ends in PATH, it's a list of file locations; they have Node() applied automatically 
17:58:15  <garyo-home>   It's *slightly* different because libs typically have pre and suffixes, and you specify them without those. 
17:58:21  <stevenknight> we do have a test for absolute paths w/CPPPATH, so it looks like that works 
17:59:04  <stevenknight> and we have tests for '#' as well, so that works 
17:59:17  <stevenknight> true re: prefixes and suffixes 
18:00:07  <garyo-home>   hm, does sound like it's inconsistent though.  What's your recommendation?  Make abs paths and # paths get turned into nodes by looking on LIBPATH? 
18:00:22  <garyo-home>   (sorry, not by looking on any path) 
18:00:20  <stevenknight> let me be real concrete:  the use case I'm running into here is someone who not only put '#foo.lib' in LIBS, but also put just 'bar.lib' without the # 
18:00:42  <stevenknight> well, now I'm going to play devil's advocate and argue with myself 
18:01:02  <stevenknight> because that does open up the can of worms about where on the slippery slope we draw the line 
18:01:13  <stevenknight> which I think might be underlying Greg's concern about this 
18:02:17  <[GregoryNoel](GregoryNoel)>  YES 
18:01:54  <garyo-home>   I'd be comfortable with abs paths; no existing lib could have such a name. 
18:02:12  <stevenknight> yeah, abs paths, and '#' 
18:02:34  <stevenknight> i'm kind of bugged by the fact that LIBS=['foo.lib'] gets turned into '-lfoo.lib' 
18:02:44  <garyo-home>   The suffix problem 
18:02:48  <stevenknight> but I don't know how to avoid that without getting really hairy about suffixes 
18:02:49  <stevenknight> yes 
18:03:08  <garyo-home>   right, what if they really wanted foo.lib.lib 
18:03:26  <garyo-home>   or whatever 
18:03:26  <[GregoryNoel](GregoryNoel)>  You begin to see the issue 
18:03:27  <stevenknight> exactly 
18:03:42  <stevenknight> so I'm not unsympathetic to both sides 
18:03:51  <garyo-home>   but that's a different issue, right?  We're only talking about / and # and maybe C:/ 
18:04:24  <[GregoryNoel](GregoryNoel)>  I say stick to your guns, keep it simple 
18:04:36  <garyo-home>   You kind of want the reverse of what Node does: something to say pass this exactly as is.  But Greg's right, one thing at a time. 
18:04:43  <[GregoryNoel](GregoryNoel)>  and don't start down the slippery slope 
18:04:58  <[GregoryNoel](GregoryNoel)>  not with /, not with #, and not with C: 
18:05:56  <garyo-home>   Greg: be specific please? 
18:06:15  <[GregoryNoel](GregoryNoel)>  Huh?  I think the issue is INVALID 
18:06:27  <[GregoryNoel](GregoryNoel)>  it works exactly as it's supposed to work 
18:06:48  <[GregoryNoel](GregoryNoel)>  and we shouldn't be in the business of being too smart 
18:07:07  <[GregoryNoel](GregoryNoel)>  about what the user (luser?) is "trying" to do 
18:07:15  <david</ins>>      Definitely 
18:07:29  <stevenknight> even when not being smart means we end up confusing the user? 
18:07:38  <david<ins>>      Many tools in python around build/distribition try to be smart, and fail miserably 
18:07:50  <[GregoryNoel](GregoryNoel)>  That's what the FAQ is for, and the mailing lists 
18:08:05  <[GregoryNoel](GregoryNoel)>  If there's really an issue, put it in the documentation 
18:08:07  <garyo-home>   ... and the workaround is always use Node() in those cases?  I think it's pretty clear what someone means if they put a / first. 
18:08:37  <[GregoryNoel](GregoryNoel)>  Pretty clear to whom? 
18:08:44  <garyo-home>   the user. 
18:08:55  <garyo-home>   They don't want -l/foo/bar/baz.lib. 
18:09:21  <[GregoryNoel](GregoryNoel)>  I think you're likely to be correct, but somebody just might. 
18:10:13  <david</ins>>      It is easier to find the workaround than understanding why it does not work in some cases because of 'magic' 
18:10:38  <[GregoryNoel](GregoryNoel)>  Instead of INVALID, how about changing the documentation to be clear about it?  With an example? 
18:10:17  <garyo-home>   I'd be (just barely) OK with documenting it in LIBS.  Use Node() if you want to pass a filename. 
18:10:52  <[GregoryNoel](GregoryNoel)>  File() in this case... 
18:11:06  <david<ins>>      That sounds like the most reasonable thing to do to me 
18:11:11  <garyo-home>   OK. 
18:11:13  <stevenknight> okay, hang on re: File() 
18:11:36  *      [GregoryNoel](GregoryNoel) is hanging.... 
18:11:37  <stevenknight> if you're going to use File() then you have to spell out everything 
18:11:43  <stevenknight> which means you end up with things like: 
18:11:51  <garyo-home>   But you already are in these cases. 
18:12:12  <stevenknight> LIBS = ['$LIBRARY_DIR/foo/${LIBPREFIX}bar{$LIBSUFFIX}') 
18:12:34  <[GregoryNoel](GregoryNoel)>  Huh?  Who ever said that? 
18:12:38  <stevenknight> sorry, LIBS=[File(_)] 
18:12:46  <stevenknight> that's the real-world use case I'm working with right now 
18:12:56  <garyo-home>   right, you need the pre/suffixes for OS independence. 
18:13:29  <garyo-home>   But you were planning on passing a full pathname anyway, right? 
18:14:07  <[GregoryNoel](GregoryNoel)>  I see; File() doesn't interpolate the variables?  What about env.File()? 
18:14:07  <[GregoryNoel](GregoryNoel)>  hello? 
18:14:25  <stevenknight> yes, env.File() 
18:14:40  <stevenknight> sorry, I'm translating between a verbal argument and an IRC argument about this real time... :-) 
18:15:02  <[GregoryNoel](GregoryNoel)>  (I'm seeing some real long latencies between when I send and when it shows up; if I seem out of sync, forgive me) 
18:15:09  <stevenknight> np 
18:15:16  <garyo-home>   ok. 
18:15:23  <stevenknight> fair point about needing to specify the file name 
18:15:41  <david</ins>>      If File does not interpolate, should it be done in File or a Lib subclass ? 
18:15:56  <stevenknight> no, you use env.File(), which does interpolate 
18:15:58  <[GregoryNoel](GregoryNoel)>  In theory, env.File() should interpolate.  Doesn't it? 
18:15:59  <garyo-home>   I think having scons do pre/suffix processing on an abs or # pathname would be gross.  Steven, you're not suggesting that? 
18:15:59  <stevenknight> i mistyped the first example 
18:16:07  <stevenknight> no, i'm not 
18:16:29  <garyo-home>   greg: yes. 
18:16:38  <stevenknight> okay, how about if we table this 
18:16:43  <stevenknight> give it to me to research 
18:16:55  <[GregoryNoel](GregoryNoel)>  I'll agree 
18:16:59  <garyo-home>   ok. 
18:16:58  <stevenknight> I'll kick around ideas here with the real-world sufferers 
18:17:17  <garyo-home>   :-) 
18:17:21  <stevenknight> and we don't discuss it again until (or if) there's a tangible proposal for changing the behavior 
18:17:30  <stevenknight> whew! 
18:18:16  <[GregoryNoel](GregoryNoel)>  Back to 2099?  (which we accidentally skipped?) 
18:18:48  <[GregoryNoel](GregoryNoel)>  Hello? 
18:19:07  <garyo-home>   Saw this on the ML. Steven understands it. I think should be fixed soon; it's a regression. 
18:19:10  <garyo-home>   1.0.x, p2. 
18:19:30  <[GregoryNoel](GregoryNoel)>  works for me 
18:19:31  <stevenknight> done 
18:19:43  <[GregoryNoel](GregoryNoel)>  2101: Consider a Solaris system with the Sun C compiler installed but without GCC installed. 
18:19:43  <[GregoryNoel](GregoryNoel)>  There are three Tools specified for the C compiler: ['aixcc', 'gcc', 'cc'] 
18:19:43  <[GregoryNoel](GregoryNoel)>  Reading that list, one assumes that the AIX is chosen in preference to GCC, which in turn is chosen in preference to a random compiler named 'cc' (which is what the documentation says), but that's not what actually happens. 
18:19:43  <[GregoryNoel](GregoryNoel)>  All three Tools recognize 'cc' as a possible name for their compiler, so all three of them detect the 'cc' command, all three return true from exists(), and all three are generated. 
18:19:43  <[GregoryNoel](GregoryNoel)>  In other words, although the _last_ Tool "wins," any setup done by the earlier tools (and not overwritten by later tools) is still around. 
18:19:43  <[GregoryNoel](GregoryNoel)>  In this case, the latter Tools don't change anything set up by the earlier tools (more accurately, they overwrite with the same values), so the configuration "works" and users can compile. 
18:19:43  <[GregoryNoel](GregoryNoel)>  Fixing this would require that each Tool detect that its tool type (C compiler in this case) had already been configured and return 'False' from exists(). 
18:19:43  <[GregoryNoel](GregoryNoel)>  Not only would this be faster, probably by a lot (only one Tool generated), it wouldn't depend on blind luck that the options are compatible. 
18:19:43  <[GregoryNoel](GregoryNoel)>  The problem is that this isn't backward compatible.  I believe it's what the semantics were supposed to be, but it's not what is implemented currently. 
18:19:43  <[GregoryNoel](GregoryNoel)>  In particular, our most common example "tools=['default','mingw']" no longer would work and would have to be changed to "tools=['mingw','default']" to get the effect intended. 
18:19:43  <[GregoryNoel](GregoryNoel)>  (Or to "tools=['mingw','default','mingw'] so it works either way.) 
18:19:43  <[GregoryNoel](GregoryNoel)>  So the real question before us in this issue is which semantics should be supported in the short term (first "wins" or last "wins"). 
18:19:43  <[GregoryNoel](GregoryNoel)>  In the longer term, the toolchain rework will make the winner the first one, so right now we can choose to match the documentation (and be incompatible) or match the implemented semantics (and change the documentation). 
18:19:43  <[GregoryNoel](GregoryNoel)>  I'm torn.  I feel the documented semantics are the right choice, but it would be a _big_ disruption. 
18:20:21  <stevenknight> damn, Greg, your typing sure got fast all of a sudden! 
18:20:32  <stevenknight> :-) 
18:20:35  <garyo-home>   rofl 
18:20:59  <[GregoryNoel](GregoryNoel)>  I practiced all week {;-} 
18:21:51  <david<ins>>      Concerning tools, my impression is that people who need some control just do it manually, no ? 
18:22:00  <stevenknight> ah, I didn't realize we're incompatible with our own doc 
18:22:39  <[GregoryNoel](GregoryNoel)>  Yes, we seem to be able to apply two different models simultaneously 
18:23:04  <david</ins>>      What is the documented semantics ? 
18:23:12  <david<ins>>      What are, sorry 
18:23:26  <david</ins>>      The one in scons man, or in the code ? 
18:23:37  <stevenknight> my gut is that since there's a good short-term workaround--namely, don't call the tool twice--that it makes more sense to defer this until the toolchain work really does it right 
18:24:06  <stevenknight> ("Doc, it hurts when I do this."  "Well, don't do that.") 
18:24:06  <[GregoryNoel](GregoryNoel)>  The man page says that the first-listed applies.  The code says that _all_ are applied. 
18:24:33  <stevenknight> whoa, wait, I think you're looking at two different lists...? 
18:24:55  <[GregoryNoel](GregoryNoel)>  (In fact, I don't know why it fails.  It should just be generated twice.) 
18:25:25  <garyo-home>   From the stacktrace, the generate doesn't fail, it fails while compiling cause something gets busted. 
18:25:28  <[GregoryNoel](GregoryNoel)>  What two different lists? 
18:25:46  <stevenknight> oh, wait, I'm sorry, I thought you were thinking of the preferences in Tool/<ins>init</ins>.py 
18:26:13  <garyo-home>   I'm trying to find the man page doc for this & failing.  Greg? 
18:26:29  <stevenknight> where does it say only the first is applied? 
18:26:30  <[GregoryNoel](GregoryNoel)>  That may be another bug, not related 
18:26:52  <david<ins>>      I don't remember having seen this either ? I thought scons manual said the last one is applied ? 
18:27:14  <stevenknight> oh, shoot, I hate to be late to the party *and* leave early 
18:27:16  <[GregoryNoel](GregoryNoel)>  Hmmm...  Doesn't it say that local compilers are chosen over FOSS toolchains? 
18:27:17  <garyo-home>   I don't see anything about lists of tools there. 
18:27:19  <stevenknight> but I'm still at work and taking the late shuttle 
18:27:26  <stevenknight> so I have to leave and get over to the stop 
18:27:34  <garyo-home>   Yes, but nothing about lists. 
18:27:55  <stevenknight> I'll connect again once I'm there in case anyone's still going 
18:28:00  <stevenknight> but don't feel obligated on my account 
18:28:02  <garyo-home>   Closest is the MingW section. 
18:28:05  <stevenknight> later 
18:28:09  <garyo-home>   bye 
18:28:09  *      stevenknight has quit ("Leaving") 
18:29:01  <garyo-home>   I don't think we can do anything about this actual bug now in any case.  You have to allow tools to be reapplied in general. 
18:29:43  <[GregoryNoel](GregoryNoel)>  I'm not finding any obvious keywords, but then I'm a terrible searcher. 
18:30:16  <[GregoryNoel](GregoryNoel)>  Wait, it says "On posix and cygwin platforms the GNU tools (e.g. gcc) are preferred by SCons, on Windows the Microsoft tools (e.g. msvc) followed by MinGW are preferred by SCons, and in OS/2 the IBM tools (e.g. icc) are preferred by SCons." 
18:30:36  <[GregoryNoel](GregoryNoel)>  That's not what's reflected in the code. 
18:30:41  <garyo-home>   I don't see a good short term fix for this bug, unless the mingw tool itself is creating a broken env the 2nd time.  I say it should wait for toolchain redo. 
18:30:51  <[GregoryNoel](GregoryNoel)>  works for me 
18:31:26  <[GregoryNoel](GregoryNoel)>  let Steven research whether there's a different bug in play that's tickled by re-applying mingw 
18:31:42  <garyo-home>   good. 
18:32:25  <[GregoryNoel](GregoryNoel)>  2102, stevenknight, [VisualStudio](VisualStudio)? 
18:32:28  <garyo-home>   2102, more Visual Studio, lump in w/ the others.  Could apply his patch but parsing vsvars.bat will be so much better. 
18:32:37  <garyo-home>   agreed. 
18:32:37  <[GregoryNoel](GregoryNoel)>  concur 
18:32:43  <david</ins>>      Argh, I should have asked Steven 
18:32:48  <david<ins>>      I have the code for this 
18:33:07  <david</ins>>      parsing vsvarsall.bat also makes possible cross compilation to x64, in theory 
18:33:41  <[GregoryNoel](GregoryNoel)>  He has the code, yes? 
18:33:41  <garyo-home>   david<ins>: yes.  Please post your code on the dev list if you can.  And you're right, it also solves issue 2013. 
18:33:43  <david</ins>>      I am not sure I understand 2103, but I don't see why parsing .bat would not work in his case 
18:34:07  <garyo-home>   sorry, yes 2103 not 2013 
18:34:07  <david<ins>>      @gary: the only reason why I did not post the code publicly is because of licensing 
18:34:16  <david</ins>>      But that may be red-herring 
18:34:34  <david<ins>>      I don't understand the difference between python license and scons (MIT) license 
18:34:40  <garyo-home>   ok.  See what you can do then.  Do you have a good way to decide which bat file to run? 
18:34:41  <[GregoryNoel](GregoryNoel)>  If there could be a licensing issue, we can't look at it. 
18:35:22  <[GregoryNoel](GregoryNoel)>  MIT license is more liberal, has fewer restrictions. 
18:35:37  <[GregoryNoel](GregoryNoel)>  IANAL, but I believe they're compatible. 
18:35:34  <david</ins>>      @Greg: my code is inspired by distutils. But the code is a rewrite. What shall I do ? 
18:35:59  <david<ins>>      (I did not get answer from the original commiter in distutils) 
18:35:59  <garyo-home>   If it's a rewrite I think we are safe enough. 
18:36:05  <david</ins>>      It is 
18:36:12  <[GregoryNoel](GregoryNoel)>  If you wrote it, pretty much from scratch, it's yours to assign as you choose 
18:36:14  <david<ins>>      Variable are different, functions are different 
18:36:36  <david</ins>>      Parsing is different, too 
18:36:51  <garyo-home>   That seems pretty clear that it's your work, not derived. 
18:36:53  <[GregoryNoel](GregoryNoel)>  Probably (IANAL) good enough 
18:37:04  <garyo-home>   Just inspired.  But IANAL either... 
18:37:19  <david<ins>>      Inspired and derivative can only be decided in court, right ? 
18:37:26  <garyo-home>   :-/ 
18:37:34  <[GregoryNoel](GregoryNoel)>  unfortunately 
18:37:46  <david</ins>>      I don't see python developer assigning me to court, though 
18:37:56  <garyo-home>   No I think you're right. 
18:38:12  <[GregoryNoel](GregoryNoel)>  Since they'd have to bring action in France or Japan, I doubt it 
18:38:35  <david<ins>>      To answer the question about vsvars.bat: I use the same technique as distutils here. I first look at the registry 
18:38:52  <david</ins>>      and if the .bat is not found, I read the VS*COMMON fenv variable 
18:39:03  <david<ins>>      Since I can check for the existence of a file 
18:39:11  <david</ins>>      even stalled registry keys do not break things 
18:39:17  <garyo-home>   OK, makes sense.  For issue 2013, might have to look in the 32-bit registry instead.  I can help w/ that. 
18:39:32  <david<ins>>      I am not a windows programmer 
18:39:37  <garyo-home>   I am. 
18:39:42  <david</ins>>      good 
18:39:53  <david<ins>>      So shall I consider the code to be safe to put in scons svn ? 
18:40:03  <david</ins>>      Shall I wait for Steven answer, maybe ? 
18:40:13  <[GregoryNoel](GregoryNoel)>  Nag him 
18:40:19  <david<ins>>      Ok 
18:40:20  <garyo-home>   Let's try you & me & Steven to make a test version of this in the next few weeks.  Yes, wait for Steven to concur. 
18:40:48  <[GregoryNoel](GregoryNoel)>  Does that get us to 2104? 
18:40:54  <garyo-home>   I think so. 
18:41:10  <david</ins>>      The easy fix is easy :) 
18:41:31  <garyo-home>   Is there any risk?  Does it change the user command line? 
18:41:33  <david<ins>>      But this can be done in a common module between msvc and posix C compilers ? 
18:41:45  <[GregoryNoel](GregoryNoel)>  I suspect it's a real defect from the fix for CCFLAGS, et.al. 
18:42:09  <david</ins>>      @Gary: anyway, it means that behavior of msvc is not consistent with all others, which sounds like a bug to me 
18:42:47  <garyo-home>   @david: maybe not, but we shouldn't change it before 1.0.  Would have to be after if it's going to change behavior. 
18:43:04  <garyo-home>   Of course (devil's advocate) if it's going to cause recompiles, maybe better now than later. 
18:43:25  <[GregoryNoel](GregoryNoel)>  Steven says 1.0.x, I say 1.0; either way, immediately 
18:44:02  <garyo-home>   OK, fine w/ me. p3 or p4. 
18:44:15  <[GregoryNoel](GregoryNoel)>  which?  I'll go with 1.0.x 
18:44:30  <david<ins>>      I don't understand why we should not change buggy behavior, which is also not consistent with documentation ? 
18:45:02  <[GregoryNoel](GregoryNoel)>  We should, but we don't want to take chances with disrupting what's working now 
18:45:01  <garyo-home>   1.0 is very nearly ready; we should not destabilize it in any way.  1.0.x is the first possible place. 
18:45:20  <[GregoryNoel](GregoryNoel)>  so 1.0.x p3? 
18:45:25  <garyo-home>   ok. 
18:45:28  <[GregoryNoel](GregoryNoel)>  done 
18:45:34  <[GregoryNoel](GregoryNoel)>  When shall we all meet again? 
18:45:34  <[GregoryNoel](GregoryNoel)>  In thunder, lightning, or in rain? 
18:45:34  <[GregoryNoel](GregoryNoel)>  Where the place? ... 
18:45:34  <[GregoryNoel](GregoryNoel)>  I'll be on holiday next week, but I believe it's Internet-connected, so I should be able to attend remotely, either Monday or Tuesday, so it's up to you guys.  I still don't know if mail will work. 
18:45:58  <david</ins>>      @Gary: understood. 
18:46:05  *      stevenknight (n=[[email protected]](mailto:[email protected])) has joined #scons 
18:46:16  <garyo-home>   My family is getting a little grumpy about me doing this every week.  But I'll be around both Monday and Tuesday. 
18:46:23  <stevenknight> hey there, anyone still around from the bug party? 
18:46:26  <stevenknight> oh, there you go 
18:46:28  <garyo-home>   Hi Steven, we're talking about schedule for next wk. 
18:46:37  <david<ins>>      For me, this time is fine 
18:46:48  <david</ins>>      sooner is ... too soon 
18:47:10  <garyo-home>   Time's good w/ me.  Monday is the usual day; that OK? 
18:47:10  <stevenknight> garyo-home:  a different time would help? 
18:47:23  <stevenknight> Monday's fine with me 
18:47:48  <garyo-home>   @steven: if it were to start around now it might help me.  But I know that's tough for some. 
18:47:49  <david<ins>>      same time ? 
18:48:20  <garyo-home>   Let's plan on same time as usual.  I'll try to do my homework properly next time.  Too bad we didn't get to any of the tickets I commented on :-/ 
18:48:44  <david</ins>>      Same time as now would be fine for me 
18:48:52  <david<ins>>      if it is more convenient for you 
18:48:54  <stevenknight> okay, same time Monday next week 
18:48:58  <[GregoryNoel](GregoryNoel)>  Now == noon? 
18:49:08  <david</ins>>      For me, now is 10:30 a.m 
18:49:30  <[GregoryNoel](GregoryNoel)>  (doing arithmetic in head) Ah, yes 
18:49:34  <david<ins>>      There is 14 hours difference with West Coast if I remember right 
18:49:52  <[GregoryNoel](GregoryNoel)>  you're UTC+9 
18:50:03  <david</ins>>      Yes 
18:50:03  <stevenknight> where? 
18:50:08  <garyo-home>   I don't want to cause trouble but starting at 9:30 or 10 my time would be easier for me, I'm GMT+4 (EDT) 
18:50:10  <[GregoryNoel](GregoryNoel)>  Japan 
18:50:21  <stevenknight> ah 
18:50:22  <[GregoryNoel](GregoryNoel)>  Er, Nippon 
18:50:24  <garyo-home>   i.e. start around now 
18:50:36  <garyo-home>   Steven, what about you? 
18:50:36  <david<ins>>      now is fine by me 
18:51:03  <stevenknight> this time works well, but i'm pretty flexible 
18:51:14  <[GregoryNoel](GregoryNoel)>  it's 18h30 or 19 o'clock for us; it would work for me 
18:51:16  <stevenknight> now is fine too 
18:51:26  <david</ins>>      I am a student, so I am the most flexible one I guess :) 
18:51:35  <stevenknight> actually, the shuttle usually drops me at 18h30 and i have a 15 min walk 
18:51:40  <stevenknight> 18h45? 
18:51:51  <[GregoryNoel](GregoryNoel)>  19 o'clock? 
18:52:00  <stevenknight> 19h00 is okay with me 
18:52:04  <stevenknight> gary, does that work for you? 
18:52:21  <stevenknight> that's 22h00 for you, after kids are in bed but maybe getting late...? 
18:52:22  <[GregoryNoel](GregoryNoel)>  Monday or Tuesday? 
18:52:22  <garyo-home>   Yes, fine.  That's 2200 for me, or 1600GMT? 
18:52:27  <stevenknight> yes 
18:52:28  <garyo-home>   Monday ok? 
18:52:43  <garyo-home>   Steven: no problem, I stay up late sometimes anyway 
18:52:51  <[GregoryNoel](GregoryNoel)>  No, 0200 UTC, I think 
18:53:05  <garyo-home>   greg: sorry, you're right of course 
18:53:13  <[GregoryNoel](GregoryNoel)>  (Always!) 
18:53:51  <stevenknight> :-) 
18:53:58  <david<ins>>      monday in the US is fine for me 
18:54:03  <[GregoryNoel](GregoryNoel)>  OK, I'll update the bug party page before I go for Monday at 19 o'clock PDT 
18:54:07  <garyo-home>   ok, great.  So I will do the data entry into tigris, from the irc log.  I'll also follow up with a couple of posters. 
18:54:13  <stevenknight> great, thanks 
18:54:42  <[GregoryNoel](GregoryNoel)>  I guess that's it, and dinner calls.  Later. 
18:54:47  <stevenknight> i'll prep next week's spreadsheet(s) and send out announcements 
18:54:50  <garyo-home>   greg: have fun on vacation! 
18:54:57  <[GregoryNoel](GregoryNoel)>  wilco 
18:54:57  <stevenknight> have a good time 
18:55:05  <david</ins>>      Steven: we were discussing visual studio revamp, and I was wondering what you think about license issues ? 
18:55:23  <stevenknight> license for...? 
18:55:25  <stevenknight> SCons code? 
18:55:33  <david<ins>>      Did you see the email I sent you last WE ? 
18:55:38  <garyo-home>   he's talking about reading vsvars.bat 
18:55:43  <garyo-home>   he has some good code 
18:55:48  <stevenknight> it's probably buried -- hang on, i can check 
18:55:52  <david</ins>>      well, I don't know if it is good 
18:56:01  <david<ins>>      but it is a start at least 
18:56:21  <david</ins>>      @steven: basically, the code started as a derivative of some code in distutils 
18:56:27  <david<ins>>      but it is a rewrite now 
18:56:40  <stevenknight> oh, right, now i remember 
18:56:47  <david</ins>>      I did not get an answer from the original comiter in python svn 
18:57:22  <david<ins>>      It is pretty trivial code, but that does not prevent potentil problems. I would think that since both projects are open sources, under similar licenses, it is not a real problem ? 
18:57:33  <stevenknight> i think in practice it's okay 
18:57:34  <david</ins>>      but I don't want to cause any trouble 
18:57:49  <stevenknight> i definitely appreciate that 
18:57:59  <stevenknight> I'd say go ahead with it 
18:58:05  <stevenknight> especialy since it's largely a rewrite now 
18:58:09  <david<ins>>      ok, I will start a branch, then 
18:58:24  <stevenknight> as you say, since the origin is open source, it's pretty unlikely to cause trouble 
18:58:29  <david</ins>>      Yes: different variables, different function names and code in functions (I support older versions of VS) 
18:58:38  <stevenknight> and if it does they can sue us for the $200 or so in the SCons bank account... :-) 
18:58:57  <david<ins>>      Shall I say in the comments it is inspired by distutils ? 
18:59:19  <stevenknight> I think it's courteous to do so 
18:59:28  <david</ins>>      I think so too 
18:59:35  <garyo-home>   yes me too. 
18:59:35  <david<ins>>      Ok, will commit to a new branch, then 
18:59:55  <garyo-home>   I am psyched to try this out! 
19:00:04  <david</ins>>      Well, there is really nothing fancy 
19:00:19  <garyo-home>   That's extremely good.  The current version is way too fancy! 
19:00:21  <david<ins>>      but this method, I understand. The original one with registry, I don't 
19:00:38  <stevenknight> david</ins>:  are you using bzr or some other interface to svn? 
19:00:44  <garyo-home>   nobody does anymore, it evolved from a nice simple idea into a Microsoft-inspired mush. 
19:00:57  <david<ins>>      Gary, since you are familiar with windows, do you know what happens if VS is installed in a different directory ? 
19:01:09  <david</ins>>      I would guess the registry key is changed accordingly 
19:01:21  <david<ins>>      but the registry is such a POS that I never know what to expect 
19:01:37  <david</ins>>      @steven: not for scons, but yes, I sometimes do. Why ? 
19:02:00  <stevenknight> just curious 
19:02:15  <garyo-home>   Yes, some registry will be different. 
19:02:39  <stevenknight> i like that you do your work on the branches 
19:02:45  <david<ins>>      I don't like it very much, though. It is too smart for its own good. What I do for scons is importing it with git, export to bzr, and prepare my patch like this 
19:02:58  <david</ins>>      Thanks, gary 
19:03:06  <stevenknight> knowing that bzr and other DVCs make branching and merging easy, I thought perhaps you were using one as a frontend 
19:03:24  <david<ins>>      Well, I never understood svn. bzr is the first source control system that made sense to me 
19:03:46  <stevenknight> i'm very interested in moving us to bzr 
19:04:05  <stevenknight> we were talking about moving hosting to launchpad for that, but it's not really mature enough 
19:04:07  <david</ins>>      The problem with bzr is launchpad 
19:04:12  <david<ins>>      There are some good things 
19:04:17  <david</ins>>      but way too complicated 
19:04:32  <david<ins>>      and there is no good developer documentation 
19:04:51  <stevenknight> yeah, seemed like too much is really opaque 
19:04:56  <david</ins>>      I would really like to be able to do most of the tasks from the command line. 
19:05:08  <stevenknight> command line++ 
19:05:12  <david<ins>>      For example, submitting/commenting bugs 
19:05:31  <david</ins>>      But also control release, series, upload of tarballs 
19:05:44  <stevenknight> agreed 
19:05:47  <david<ins>>      For bugs, there is a xmlrpc thing 
19:05:58  <david</ins>>      bug I don't know anything about those technologies 
19:06:12  <stevenknight> right now i'm thinking about code.google.com 
19:06:34  <garyo-home>   cool idea! 
19:06:36  <stevenknight> which is svn, but maybe use bzr as the standard frontend 
19:06:45  <stevenknight> yeah, at first I thought it didn't have what we want 
19:06:54  <stevenknight> but it's actually got a pretty good bug tracker, and a wiki built in 
19:07:13  <garyo-home>   I just used google data 1st time last night, very smooth & easy.. Do these use the same APIs? 
19:07:14  <david<ins>>      @steven: I am not sure I would recommend it (bzr as a frontend with svn backend) 
19:07:31  <stevenknight> not quite all the features we need in the bug tracker, though -- no date-range searches 
19:07:59  <garyo-home>   I know Greg doesn't like Trac, but we use it here and it is *very* nice.  Not sure about bzr integration though. 
19:08:17  <stevenknight> i'm not 100% sure about google data + code. 
19:08:24  <garyo-home>   Integrated wiki, milestones, tickets, log browser, source browser. 
19:08:41  <stevenknight> but there's pretty good integration in a lot of the google stuff 
19:08:49  <david</ins>>      I don't like trac either 
19:08:54  <stevenknight> so it'll probably happen some day if it's not already available 
19:09:03  <david<ins>>      trac+bzr is not a good idea 
19:09:03  <garyo-home>   And google's behind it which is important! 
19:09:13  <stevenknight> yep! 
19:09:21  <david</ins>>      if bzr is chosen, then launchpad is pretty much the only choice ATM 
19:09:24  <garyo-home>   david: I've heard the same from others.  Not ready for prime time yet. 
19:09:37  <garyo-home>   What about other dvcses? 
19:09:39  <stevenknight> david<ins>:  what problems have you had/heard about with bzr+svn? 
19:09:51  <david</ins>>      Well, first, it is difficult to install 
19:10:05  <david<ins>>      Because python wrappers around svn are buggy 
19:10:11  <stevenknight> i have to disconnect and switch buses, will reconnect right away 
19:10:14  <garyo-home>   ... and being a plugin it's a 2nd class citizen. 
19:10:32  <david</ins>>      @gary: I have some limited experience with mercurial and git 
19:10:42  <david<ins>>      I am not aware of any bug tracking system with mercurial 
19:10:51  <david</ins>>      git is without any question the most powerful 
19:10:56  <david<ins>>      it is pretty amazing 
19:11:01  <david</ins>>      but can be complicated 
19:11:15  <garyo-home>   what's complicated?  Simple things, or complicated things? 
19:11:18  <david<ins>>      and I don't know its status on windows  
19:11:26  <david</ins>>      The nature of the tool is complicated 
19:11:30  <garyo-home>   i see. 
19:11:45  <david<ins>>      For example, if you do git add and git commit, it will not add anything 
19:11:58  <david</ins>>      also, git (and mercurial) do have multi branch in a tree 
19:12:05  <garyo-home>   Was there some talk of wrappers to simplify it? 
19:12:06  <david<ins>>      Which is arguably more powerful sometimes 
19:12:12  <david</ins>>      bzr, with one branch is one directory 
19:12:17  <david<ins>>      is definitely simpler 
19:12:30  <garyo-home>   yes, less mental bookkeeping 
19:12:36  <david</ins>>      Another key difference between bzr and git/mercurial is the mainline concept 
19:12:47  <david<ins>>      in bzr, when you merge a branch into another one 
19:12:56  <david</ins>>      the history is not flat 
19:13:09  <david<ins>>      which bugs git/mercurial users 
19:13:30  <david</ins>>      But has a great advantage: you can guarantee that every commit of the mainline is correct (pass test, etc...) 
19:13:48  <david<ins>>      I feel that bzr fits more the way scons development works 
19:13:58  <david</ins>>      but I am not that familiar with scons development yet 
19:14:03  <stevenknight> hey, looks like i went from bus to bus without having to drop the irc connection... 
19:14:07  <stevenknight> cool 
19:14:09  <garyo-home>   makes sense.  Maybe we just keep thinking about it for a while. 
19:14:37  <garyo-home>   Maybe launchpad will get better, or code.google.com will support bzr as a front end. 
19:14:48  <david<ins>>      I think the choice really is DVCS+tracker 
19:14:56  <david</ins>>      you could choose independently 
19:15:01  <david<ins>>      but in practice, you can't 
19:15:11  <garyo-home>   I think you're right. 
19:15:22  <david</ins>>      Well, you can't if you want free hosting, at least 
19:15:51  <david<ins>>      I will try github.com, too. Which is open source 
19:16:11  <david</ins>>      gitorious, sorry. Github is commercial, the one user by RoR 
19:16:37  <stevenknight> well, if we do go with code.google.com, the silver lining would not having to change the underlying SCM 
19:16:55  <garyo-home>   Steven: with google, would it have to be "Google SCons"? :-) 
19:17:03  <david<ins>>      What are the advantages of google code ? 
19:17:04  <stevenknight> LOL 
19:17:17  <david</ins>>      You are at google, right, steven ? 
19:17:28  <stevenknight> there sems to be a path where things start out being named "google X" and then eventually get shortened 
19:17:32  <stevenknight> yes, i'm at google now 
19:17:50  <stevenknight> that's one reason to look more closely at code.google.com, but not the most important one 
19:18:09  <stevenknight> i'm more interested in making sure we get a good development process, regardless of where it's hosted 
19:18:11  <david<ins>>      Personally, I am more interested in changing the source control system than the ticket system 
19:18:25  <garyo-home>   +1 
19:19:01  <david</ins>>      But I guess I am special: I don't understand a single argument about why svn could be better than git or bzr (except for huge binary files, which is no concern for us) 
19:19:37  <garyo-home>   for us (non open source, proprietary code), a centralized vcs makes much more sense and keeps things simple. 
19:19:39  <stevenknight> i didn't realize people were still arguing that svn is better than the DVCSs out there 
19:19:59  <garyo-home>   For a distributed project, nobody could argue in favor of svn! 
19:20:08  <stevenknight> right 
19:20:38  <david<ins>>      @Gary: but git and bzr can have a centralized VCS 
19:20:53  <stevenknight> garyo:  have you seen Linus Torvald's talk at Google where he trashes svn? 
19:21:06  <garyo-home>   yes, but for us it wouldn't gain us much.  Steven: yes, the famous talk. 
19:21:07  <david</ins>>      But anway, I did not want to argue about DVCS against centralized. I just don't see any advantage of svn in my cases 
19:21:40  <garyo-home>   you're both right, and I'll migrate [GenArts](GenArts) (my company) to a dvcs probably in 18 months - 2 years. 
19:21:43  <stevenknight> actually, i took away from that talk one very important thing about SCons (by analogy) 
19:22:12  <stevenknight> i really like his point that by making branching O(1), svn was optimizing the wrong thing 
19:22:22  <stevenknight> because that's done so much less than merging 
19:22:44  <david<ins>>      yes. Nobody does merging with svn. It does not work 
19:22:44  <garyo-home>   so true! 
19:22:49  <stevenknight> I think you can make exactly the same point about SCons w.r.t. having emphasized full-tree builds over incremental builds 
19:23:02  <garyo-home>   We have a workflow that does work, but it is highly restricted. 
19:23:27  <garyo-home>   steven: I see what you're getting at.  Incremental builds are done 100x/day, full builds rarely. 
19:23:36  <stevenknight> right 
19:23:55  <stevenknight> and it's not that corretness isn't important, but if the full build takes a little more time, it's lost in the noise 
19:24:02  <stevenknight> but everyone notices the incremental slowdown 
19:24:20  <garyo-home>   True.  Subdir builds can help some. 
19:24:30  <david</ins>>      What are the plans for 1.0 and after ? 
19:24:43  <david<ins>>      I mean, what's missing for 1.0 ? 
19:24:49  <stevenknight> nothing 
19:25:05  <stevenknight> we're just letting 0.98.5 cook a little more while we write doc 
19:25:15  <stevenknight> it'll become 1.0 
19:25:27  <stevenknight> and then we argue about how soon to branch for 2.0  :-) 
19:25:38  <stevenknight> i'm actually with Bill Deegan, I want to move on to 2.0 quickly 
19:25:39  <garyo-home>   hey guys, have to go.  See you next Monday. 
19:25:45  <stevenknight> 2.0 drops compatibility with 1.5.2 
19:25:52  <stevenknight> thanks gary -- catch you later 
19:25:58  <stevenknight> Python 1.5.2, that is 
19:26:00  <david</ins>>      (I just measured the size of scons core: in bzr, the full branch takes 45 Mb, vs 37 Mb for a svn checkout) 
19:26:07  <david<ins>>      see you 
19:26:26  <stevenknight> So SCons 2.0 will be written to work on Python 2.2 and later 
19:26:32  <david</ins>>      great 
19:26:47  <david<ins>>      to me, that's one of the main showstopper 
19:26:44  <stevenknight> that lets us git rid of all sorts of map() and filter() calls in favor of list comprehensions 
19:26:51  <stevenknight> which should speed up a lot of stuff 
19:26:58  <david</ins>>      Getting rid of eval is more important IMO 
19:26:58  <stevenknight> understood 
19:27:19  <david<ins>>      Because it makes the code difficult to profile 
19:27:23  <david</ins>>      and to understand 
19:27:25  <stevenknight> so it can be run with psyco? 
19:27:31  <stevenknight> ah 
19:27:34  <david<ins>>      This, I don't know 
19:27:40  <david</ins>>      But I know scons is difficult to profile 
19:28:06  <stevenknight> hmm, i didn't think eval() was that much of an issue for profiling 
19:28:16  <stevenknight> where is it getting in the way for you? 
19:28:18  <david<ins>>      You don't know what's executed ? 
19:28:47  <stevenknight> but we're not doing that much eval'ing, except in string substituion when ${} is used 
19:28:48  <david</ins>>      With cProfile, at least (python profile is useless for big projects) 
19:28:50  <stevenknight> is that what you're referring to? 
19:28:53  <david<ins>>      no 
19:28:59  <david</ins>>      let me check 
19:29:44  <stevenknight> BTW re: cProfile: how do its results compare with python profile? 
19:29:54  <david<ins>>      It is much faster 
19:29:57  <stevenknight> does it give exactly the same, or are you comparing apples-and-oranges 
19:30:03  <stevenknight> that's it's execution speed 
19:30:16  <stevenknight> what about the code it's measuring? 
19:30:22  <david</ins>>      The problem with profile is that for example a noop build is like 10 times slower 
19:30:30  <david<ins>>      so it is basically useless 
19:30:59  <david</ins>>      so much overhead that it is measuring a totally different thing that what you run normally 
19:31:21  <david<ins>>      For example, I build lapack with scons. Lapack is an old fortran library: one function per file, 2000 files 
19:31:37  <david</ins>>      a No op build is taking 10 seconds. But with python profile, it is taking 2 minutes IIRC 
19:31:54  <david<ins>>      So you are not really measuring the same thing. 
19:32:10  <stevenknight> let me make this more concrete:  i have a lot of timig data that I've generated with python profile over the last 1000 or so checkins 
19:32:46  <stevenknight> is the code execution they're measuring determinstic such that I can meaningfully compare python profile results with cProfile results? 
19:32:58  <david</ins>>      I am not sure 
19:33:09  <stevenknight> or if we switch to cProfile to I have to go back and re-generate 1000 change sets worth of timing data? 
19:33:25  <stevenknight> right, that's my dilemma 
19:34:01  <stevenknight> i haven't found anything that answers whether or not the time units *being measured* are deterministic between the two implementations 
19:34:07  <david<ins>>      [http://docs.python.org/lib/node794.html](http://docs.python.org/lib/node794.html) 
19:34:34  <david</ins>>      They say they are interchangeable, but they only talk about the API 
19:34:42  <stevenknight> right 
19:35:12  <david<ins>>      One problem kind of specific to scons 
19:35:19  <david</ins>>      is that it is using a lot of functions 
19:35:32  <david<ins>>      which is extremely slow with python; and python profile makes it much slower 
19:35:52  <david</ins>>      I guess this is the main problem with python profile 
19:36:02  <stevenknight> yes 
19:36:32  <stevenknight> in addition to updating the baseline Python release we support, I'm going to put some serious effort into optimizing incremental builds 
19:36:49  <stevenknight> right now one of the big killers is the scanning of directories like CPPPATH 
19:36:59  <stevenknight> directory paths, i should say 
19:37:18  <stevenknight> there's basically a O(n^2) algorithm in there that explodes the function call counts 
19:37:32  <david<ins>>      T. Nagy also said that "compiling" actions strings to functions speeds things a lot 
19:37:36  <stevenknight> i think we can make the path search O(1) 
19:37:47  <stevenknight> that makes sense 
19:37:50  <david</ins>>      Is this something doable ? 
19:38:01  <stevenknight> yes, i think so 
19:38:04  <david<ins>>      There are some things which are much faster in waf, and I don't see why scons is slower 
19:38:13  <david</ins>>      for configuration checks, for example 
19:38:29  <stevenknight> i have a half-finished re-implementation of Subst.py that separates the string parse from the expansion 
19:38:34  <stevenknight> right now we do both every time 
19:38:38  <stevenknight> that might be in the same direction 
19:39:03  <stevenknight> more and more i'm finding that our slowness is dumb implementatiions 
19:39:07  <stevenknight> not so much incorrect ideas 
19:39:12  <david<ins>>      Would having scons as a python library possible at all ? 
19:39:15  <david</ins>>      Well, that's good. 
19:39:19  <stevenknight> things that grew over time in ways not originally envisioned 
19:39:23  <david<ins>>      It means if is fixable 
19:39:29  <david</ins>>      it is fixable, sorry 
19:39:35  <stevenknight> so far i haven't found anything that doesn't look fixable 
19:39:49  <stevenknight> do you mean scons as a standard python library? 
19:40:17  <david<ins>>      yes 
19:40:28  <david</ins>>      I am afraid this would be extremely complicated 
19:40:36  <stevenknight> probably 
19:40:41  <david<ins>>      but this would be a killer. 
19:40:56  <stevenknight> the topic came up very briefly at a SCons BOF with Guido and Alex several years ago 
19:40:57  <david</ins>>      Ok, I was wrong, as I expected: I was talking about apply, not eval 
19:41:21  <stevenknight> Guido sounded skeptical, i think because SCons seems too application-specific 
19:41:23  <david<ins>>      People in numpy/scipy were also a bit afraid of that, when I started using it to build numpy/scipy 
19:41:36  <stevenknight> it's hard to see it as a generic library that people want to re-use in different contexts 
19:41:40  <david</ins>>      I think the general ideas make a lot of sense 
19:41:47  <stevenknight> yes re: the over-use of apply() 
19:41:56  <david<ins>>      build/distribution is really a big PITA in python right now 
19:42:05  <stevenknight> yes! 
19:42:25  <stevenknight> and so-called "easy" install only complicated things for packagers, in my view... 
19:42:46  <david</ins>>      about apply: this is due to python 1.5, right ? apply is what makes profiling difficult, not eval (there are not many eval in scons) 
19:42:58  <david<ins>>      Don't get me started with setuptools :) 
19:43:20  <stevenknight> right, I've been adopting more and more functional programming idioms over time 
19:43:26  <stevenknight> and apply() is how you do that in 1.5 
19:43:42  <stevenknight> so all of those can get turned into list comprehensions once we get 1.0 out the door 
19:43:58  <stevenknight> or, heck, should just be turned into loops if that's more efficient 
19:44:21  <david</ins>>      I don't know if it is slow, but knowing you have a lot of apply is not helpful when profiling 
19:44:29  <david<ins>>      it is like lambda 
19:44:42  <david</ins>>      maybe dtrace can be smart about that, never tried. 
19:45:36  <david<ins>>      Ok, I am starting the vs_revamp branch 
19:46:09  <stevenknight> cool 
19:46:39  <stevenknight> does there seem to be much (if any) work going into bzr-svn to make it more viable? 
19:47:00  <david</ins>>      If you don't care about branches 
19:47:04  <david<ins>>      then it is usable 
19:47:08  <david</ins>>      but slow 
19:47:21  <david<ins>>      which should not matter much for scons, though 
19:47:52  <stevenknight> hmm, not caring about branches seems to lose one of the big advantages of a DVCS... 
19:48:17  <david</ins>>      the problem is the svn backend 
19:48:28  <david<ins>>      git-svn does not deal that well either 
19:48:35  <stevenknight> ah 
19:48:37  <david</ins>>      you can do bzr branch on svn repositories 
19:48:47  <david<ins>>      but honestly... 
19:48:57  <david</ins>>      I don't do it 
19:49:04  <david<ins>>      For numpy/scipy, I create the branches by hand 
19:49:08  <david</ins>>      with svn 
19:50:23  <stevenknight> makes sense 
19:50:27  <david<ins>>      Would it make sense to use google code with something else for code repository ? 
19:50:47  <stevenknight> possibly 
19:51:00  <stevenknight> i certainly don't think they care if you only use parts of the hosting service 
19:51:31  <stevenknight> my bus stop is coming up soon 
19:51:34  <david</ins>>      I meant from a practical POV 
19:51:48  <stevenknight> not sure how well that would work in practice 
19:52:01  <stevenknight> curious:  have you been in Japan long? 
19:52:23  <david<ins>>      Since I will try git hosting, would you like me to write something on the wiki/ML about it, how it compares to launchpad ? 
19:52:26  <david</ins>>      4 years 
19:52:36  <david<ins>>      2 years working, 2 years of PhD so far 
19:52:39  <stevenknight> re: git hosting, that would be fine 
19:52:55  <stevenknight> my brother was in Tokyo for many years; his wife is Japanese 
19:53:08  <david</ins>>      Oh 
19:53:14  <david<ins>>      Never lived in Tokyo 
19:53:33  <stevenknight> have to leave the bus now -- good chating w/you 
19:53:39  <david</ins>>      If going into academia does not go as I want, I am thinking about trying working at Google in Tokyo :) 
19:53:39  *      stevenknight has quit ("Leaving") 
20:19:31  *      david<ins> has quit ("Leaving") 
20:28:56  *      garyo-home has quit (Read error: 104 (Connection reset by peer))