-
-
Notifications
You must be signed in to change notification settings - Fork 313
IrcLog2008 06 17
William Deegan edited this page Jan 14, 2016
·
2 revisions
17:00:52 <[GregoryNoel](GregoryNoel)> It's time. Who's where for the bug party?
17:01:24 * garyo-home (n=[chatzill@209-6-158-38.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com](mailto:chatzill@209-6-158-38.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com)) 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=[chatzill@209-6-158-38.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com](mailto:chatzill@209-6-158-38.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com)) has joined #scons
17:07:13 * david<ins> (n=[david@mail.ar.media.kyoto-u.ac.jp](mailto:david@mail.ar.media.kyoto-u.ac.jp)) 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=[stevenkn@69.36.227.130](mailto:stevenkn@69.36.227.130)) 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))