IrcLog2008 06 17

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