Please note:The SCons wiki is in read-only mode due to ongoing spam/DoS issues. Also, new account creation is currently disabled. We are looking into alternative wiki hosts.
   1 17:00:52 <GregoryNoel>	It's time.  Who's where for the bug party?
   2 17:01:24 *	garyo-home ( has joined #scons
   3 17:01:47 <garyo-home>	Hi folks.
   4 17:01:57 <GregoryNoel>	Folk, singular.
   5 17:02:17 <garyo-home>	Hi, Greg.
   6 17:02:39 <GregoryNoel>	Hi...  Nobody here but me and thee.
   7 17:02:52 <garyo-home>	ok, let's wait a bit then.
   8 17:03:05 <GregoryNoel>	yup
   9 17:03:28 <GregoryNoel>	I notice you haven't marked up the current issues.  Nothing to say?
  10 17:03:43 <garyo-home>	I assume Steven's on his way, he did the spreadsheet etc.
  11 17:04:20 <garyo-home>	re: current issues: no, I missed them :-(, did all the old ones.
  12 17:04:46 <GregoryNoel>	yes, he did, but basically only he and I marked them up.
  13 17:05:15 <garyo-home>	I did a bunch of old ones actually.
  14 17:05:20 *	GregoryNoel overrun by puppy, hang on
  15 17:05:34 <garyo-home>	Grr, current spreadsheet isn't letting me in yet...
  16 17:06:14 *	garyo-home has quit (Client Quit)
  17 17:07:10 *	garyo-home ( has joined #scons
  18 17:07:13 *	david__ ( has joined #scons
  19 17:07:37 <GregoryNoel>	Ho, David; welcome back, Gary
  20 17:07:44 <garyo-home>	Hi again guys.
  21 17:08:00 <garyo-home>	I still can't write the current issue spreadsheet but I guess it's too late anyway :-(
  22 17:08:10 <david__>	hello everyone
  23 17:08:34 <GregoryNoel>	It worked fine for me; why do you keep having problems?
  24 17:08:19 <david__>	Am i late ?
  25 17:08:39 <garyo-home>	no, we're waiting to see who else shows up, hopefully Steven.
  26 17:08:55 <garyo-home>	Greg: bad behavior in previous life perhaps?
  27 17:09:13 <GregoryNoel>	Must be.  Or maybe you're overthinking it.
  28 17:09:10 <garyo-home>	Maybe Firefox issue?
  29 17:09:30 <GregoryNoel>	Not Firefox; works for me.
  30 17:09:33 <garyo-home>	Some of them work no prob, others dont.
  31 17:09:44 <garyo-home>	Individual invites have always worked.
  32 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 :)
  33 17:10:19 <garyo-home>	No, they're usually fine foe me.
  34 17:10:19 <GregoryNoel>	They're not fast, but one copes.
  35 17:10:53 <GregoryNoel>	david__, do you use Firefox?
  36 17:10:58 <david__>	Yes
  37 17:11:13 <GregoryNoel>	2.0.0.whatever?
  38 17:11:23 <david__>	firefox 2. something. Other people had problems with it on ubuntu
  39 17:11:34 <david__>	With spreadsheet, I mean. 
  40 17:11:53 <GregoryNoel>	Hmmm...  Works fine on my Mac.
  41 17:12:14 <garyo-home>	I'm using ffox 2.0 on win xp.  I'll try Ubuntu sometime.
  42 17:12:16 <GregoryNoel>	Maybe you should get yourself a new computer {;-}
  43 17:12:28 <GregoryNoel>	Both of you...
  44 17:12:30 <david__>	It's a bi-cpu, pentium 4
  45 17:12:32 <garyo-home>	... or a new OS
  46 17:12:54 <garyo-home>	my hw is fine, fast core 2 duo, 2gb etc.
  47 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
  48 17:13:41 <garyo-home>	david__, you're right.
  49 17:13:46 <GregoryNoel>	Humpf.  PPC 1Ghz rules.
  50 17:13:43 <david__>	I think there is a bad interaction between ubuntu themes, my hardware and firefox.
  51 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
  52 17:15:16 <GregoryNoel>	We work through the issues and decide where they should go (which milestone and priority)
  53 17:15:54 <david__>	Which spreadsheets are used, besides the current issues one ?
  54 17:16:10 <GregoryNoel>	The next one not ticked off
  55 17:16:12 <garyo-home>	HA - I can open the spreadsheet just fine (r/w) on Ubuntu Hardy in a VM.
  56 17:16:26 <GregoryNoel>	with luck, the one after that
  57 17:16:36 <GregoryNoel>	and maybe the one after that.
  58 17:16:59 <garyo-home>	OK, maybe Steven's not coming?
  59 17:17:01 <david__>	@gary: yes, that's the strange thing, it works better in vm on my another computer
  60 17:17:22 <garyo-home>	Should we just start and see what we can do?
  61 17:17:30 <GregoryNoel>	I'm ready
  62 17:17:43 <GregoryNoel>	1643?
  63 17:17:58 <GregoryNoel>	Has anyone been in contact with Brandon?
  64 17:18:03 <garyo-home>	not me.
  65 17:18:27 <garyo-home>	pass back to OP for more info?
  66 17:18:45 <GregoryNoel>	I'm really hesitant to pass over this again, but I don't see any other course.
  67 17:18:58 <GregoryNoel>	I don't think the OP has any more info.
  68 17:19:11 <garyo-home>	How about ask him for the config log.
  69 17:19:51 <GregoryNoel>	huh.  Somebody named "sharing" just opened the spreadsheet.  Is that you, David?
  70 17:19:57 <garyo-home>	Or whether it's all in the same run or separate runs.  And to please post the SConstruct.
  71 17:20:30 <GregoryNoel>	OK, but not me, I'm on holiday.  Can you take it?
  72 17:20:38 <garyo-home>	Sure.
  73 17:20:51 <GregoryNoel>	garyo, research, done
  74 17:21:01 <GregoryNoel>	1675?
  75 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...
  76 17:21:38 <garyo-home>	1675: wine bug, close.
  77 17:21:52 <GregoryNoel>	done
  78 17:22:01 <GregoryNoel>	2089
  79 17:22:39 <GregoryNoel>	I think the two-variable solution is the right course, but when?
  80 17:22:48 <garyo-home>	enhancement req: 2.x p3
  81 17:22:59 <GregoryNoel>	Hmmm....  OK
  82 17:23:13 <GregoryNoel>	wait, 2.x?  Not 1.x?
  83 17:23:20 <garyo-home>	I could go with that.
  84 17:23:41 <garyo-home>	It's supposed to be really simple, right?  Just pass the flag to compiler?
  85 17:23:44 <GregoryNoel>	I think it needs to be sooner rather than later, and it doesn't look that complex.
  86 17:23:49 <garyo-home>	ok, 1.x.
  87 17:23:54 <GregoryNoel>	Two flags, yeah.
  88 17:24:09 <GregoryNoel>	p3?
  89 17:24:30 <garyo-home>	that's my default
  90 17:24:39 <GregoryNoel>	OK, for Steven?
  91 17:24:49 <garyo-home>	yes
  92 17:24:54 <GregoryNoel>	1.x, p3, steven, done
  93 17:25:01 <GregoryNoel>	2095?
  94 17:25:43 <GregoryNoel>	1.x+symlink, p4, me
  95 17:25:57 <garyo-home>	Right, I think your ssheet comment is good.
  96 17:26:20 <GregoryNoel>	It's how I'd expect it to work {;-}
  97 17:27:01 <GregoryNoel>	no other comments?  Done then?
  98 17:27:18 <david__>	I don't understand the issue, never use symlinks in builds :)
  99 17:27:20 <garyo-home>	ok.
 100 17:27:31 <GregoryNoel>	done
 101 17:27:36 <GregoryNoel>	2096?
 102 17:27:40 <garyo-home>	david__: not sure we'll ever handle them 100% perfectly, but we can do better.
 103 17:27:54 <garyo-home>	2096: research.
 104 17:28:06 <GregoryNoel>	I'm game
 105 17:28:08 <david__>	Is it something scons is supposed to support or not ?
 106 17:28:19 <GregoryNoel>	Good question.
 107 17:28:27 <GregoryNoel>	It should support it, but how?
 108 17:28:50 <GregoryNoel>	Should all configuration be global?  Or should all configuration be local?
 109 17:28:34 <garyo-home>	Each one independently, yes.  Together: probably should, just haven't thought it through.
 110 17:28:57 <GregoryNoel>	Or some combination of both?
 111 17:29:04 <GregoryNoel>	It's not obvious.
 112 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
 113 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.
 114 17:29:42 <GregoryNoel>	That's why I posed the question
 115 17:29:40 <garyo-home>	david__: you can use --srcdir for that.  mkdir build; cd build; scons --srcdir ..
 116 17:30:13 <garyo-home>	anyway, we shouldn't design it here & now.
 117 17:30:19 <garyo-home>	research, steven.
 118 17:30:26 <GregoryNoel>	True...  agree
 119 17:30:41 <david__>	ok.
 120 17:30:39 <GregoryNoel>	2097?
 121 17:30:59 <david__>	The problem of 2097 is different than 2096, I believe
 122 17:31:06 <david__>	but if we don't support 2096, then...
 123 17:31:13 <GregoryNoel>	Question here is whether this ends up the same issue as 2096
 124 17:31:20 <david__>	The problem is in TryRun
 125 17:31:45 <david__>	Building and linking works fine, but the run the target is not aware of BuildDir
 126 17:31:53 <GregoryNoel>	But TryRun is part of SConf, and it should figure out where things should go.
 127 17:32:03 <garyo-home>	2097 doesn't say anything about TryRun ??
 128 17:32:32 <GregoryNoel>	In the description, I think
 129 17:33:02 <david__>	Argh, you're right gary, sorry, I mixed up things
 130 17:33:02 <GregoryNoel>	Both are about where the build tests are made and where the results go
 131 17:33:13 <garyo-home>	huh?  2097 = scons is confused when configuration checks are put into build dir set by VariantDir  ?
 132 17:33:28 <david__>	The problem of 2097 is with the sconsign file
 133 17:33:35 <garyo-home>	david__: right.
 134 17:33:40 <david__>	when sconsign is put into the build-dir
 135 17:34:04 <garyo-home>	david__: actually, when it's *not* in the build dir things can get confused.
 136 17:34:35 <david__>	Well, in that case, when build dir is not used, it works as expected ? What do you mean ?
 137 17:34:43 <garyo-home>	but I agree it should check that the files still exist before thinking the file is uptodate.
 138 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.
 139 17:35:31 <david__>	ah
 140 17:35:48 <garyo-home>	Anyway, it is a bug I think; scons should not think a nonexistent file is up to date!
 141 17:35:53 <david__>	yes
 142 17:36:14 <GregoryNoel>	so, research, steven?
 143 17:36:15 <garyo-home>	1.x p3 IMHO; who should get configure things?
 144 17:36:23 <garyo-home>	steven I guess
 145 17:36:49 <GregoryNoel>	I think these two should be kept as a pair and assigned the same place
 146 17:36:52 <david__>	how do you decide between 1.x and 2.x ?
 147 17:37:01 <GregoryNoel>	WAG
 148 17:37:10 <garyo-home>	:-)
 149 17:37:18 <david__>	WAG meaning ?
 150 17:37:32 <GregoryNoel>	Oh, sorry, that's an anagram of "wild-ass guess"
 151 17:37:33 <garyo-home>	1.0: severe bug.  1.x: should be fixed soon, or hi pri enh req.  2.x: everything else.
 152 17:37:45 <garyo-home>	how's that?
 153 17:37:48 <david__>	ok, one new acronym for me
 154 17:38:01 <GregoryNoel>	yes, acronym
 155 17:38:17 <garyo-home>	I don't think 2096 and 2097 are the same; they can be assigned differently.
 156 17:38:28 <GregoryNoel>	You forgot 1.0.x and future.
 157 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.
 158 17:39:29 <david__>	I think 2097 is more sever than 2096, no ?
 159 17:39:40 <david__>	2096 just does not work. But 2097 is quite surprising
 160 17:39:44 <garyo-home>	david__: and probably easier to fix.
 161 17:39:55 <garyo-home>	(2097 easier than 2096)
 162 17:40:05 <david__>	yes
 163 17:40:05 <GregoryNoel>	Both have to do with location of files
 164 17:40:20 <GregoryNoel>	I'll bet if you fix one, the other is 90% done
 165 17:40:41 <garyo-home>	If you fix 2096, 2097 might go away, but not the other way round.
 166 17:40:55 <garyo-home>	anyway, how about a note in each one referring to the other.
 167 17:41:00 <GregoryNoel>	works
 168 17:41:20 <david__>	I don't understand the implications enough, so nothing to say
 169 17:41:26 <GregoryNoel>	so you wanted 1.x p3: I'll go for that
 170 17:41:33 <david__>	sorry, I meant for issues 2096-2097
 171 17:41:56 <garyo-home>	Greg: 2097 1.x p3? yes.
 172 17:42:04 <GregoryNoel>	done
 173 17:41:18 <garyo-home>	2098: has patch, good!
 174 17:42:23 <GregoryNoel>	2098, I'm not sure the patch will fly as is
 175 17:42:40 <garyo-home>	haven't looked at it.
 176 17:42:57 <GregoryNoel>	It's too simple; special case for python and java, nothing else
 177 17:43:19 <GregoryNoel>	so if you had -python -tcl as parameters, it would fail.
 178 17:43:33 <garyo-home>	I see.  OK, so pass back to OP with comments?
 179 17:43:40 <GregoryNoel>	I mean SCons would fail, since it wouldn't get the output right.
 180 17:43:56 <garyo-home>	Right, understood.
 181 17:43:58 <GregoryNoel>	Hmmm...  Sure, we can try that; review next week?
 182 17:44:05 <garyo-home>	Ask OP to improve patch and resubmit.
 183 17:44:10 <GregoryNoel>	done
 184 17:44:14 <garyo-home>	I'll do it.
 185 17:44:43 <GregoryNoel>	somebody will have to do most of them; I won't be around
 186 17:45:15 <garyo-home>	OK, if you email me the irc log I'll do the data entry.
 187 17:45:41 <GregoryNoel>	I can set up the IRC page; I have the tools, but that will be pretty much it.
 188 17:46:24 <garyo-home>	ok, that's fine.  I'll look there.
 189 17:46:31 <GregoryNoel>	2100?
 190 17:46:37 <garyo-home>	I may have logging enabled here too.  OK, 2100...
 191 17:47:18 <garyo-home>	Saw this on the ML.  Steven understands it.  I think should be fixed soon; it's a regression.
 192 17:47:29 <GregoryNoel>	I don't agree.
 193 17:47:37 <garyo-home>	ok?
 194 17:47:37 <david__>	How supporting # in LIBS makes linking more platform independant ?
 195 17:47:55 <GregoryNoel>	Not a platform-dependent issue.
 196 17:47:57 <garyo-home>	umm.  never mind, I was looking at 2099.  Sorry.
 197 17:48:16 <GregoryNoel>	Ah, we skipped one...
 198 17:48:21 <GregoryNoel>	2099!
 199 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
 200 17:48:56 <garyo-home>	ok, 2099 I say 1.0 or 1.0.x, p2.  Regression.
 201 17:49:04 <GregoryNoel>	Let's finish 2100 and then go back
 202 17:49:10 <garyo-home>	ok
 203 17:49:26 *	stevenknight (n=stevenkn@nat/google/x-bf5612cd2f2152ca) has joined #scons
 204 17:49:34 <stevenknight>	hey, anyone still here?
 205 17:49:38 <garyo-home>	Hi, Steven!
 206 17:49:42 <GregoryNoel>	No, we've all left
 207 17:49:58 <GregoryNoel>	We're arguing over 2100
 208 17:50:15 <stevenknight>	sorry about that, got pulled into one of those urgent impromptu meetings
 209 17:50:15 <garyo-home>	2100: if it's a pathname, why not use ./ if the libname is foo and you don't want it turned into top-relative?
 210 17:50:35 <garyo-home>	steven: we just gave you all the bugs, p1, 1.0.
 211 17:50:39 <GregoryNoel>	It's _not_ a pathname!
 212 17:50:42 <stevenknight>	excellent
 213 17:50:44 <garyo-home>	;-)
 214 17:50:54 <GregoryNoel>	It's a library name.
 215 17:51:04 <garyo-home>	He says path name.
 216 17:51:15 <stevenknight>	historically, it's been a library name
 217 17:51:27 <GregoryNoel>	If you put a bare string in LIBS, it gets wrapped.
 218 17:51:28 <stevenknight>	my question is:  is there a reason why it can't also refer to an actual *library*?
 219 17:51:33 <stevenknight>	either as a node or a path name?
 220 17:51:52 <GregoryNoel>	How can you tell?  Library names can be anything, including 'm'
 221 17:52:03 <garyo-home>	I use Nodes, but I think abs pathnames work too.  Maybe # is turning it *into* a pathname?
 222 17:52:20 <garyo-home>	Greg: begins with / or is a Node.
 223 17:52:33 <stevenknight>	garyo-home:  Nodes in LIBS, or Nodes in the SOURCES list?
 224 17:52:38 <GregoryNoel>	I can't check quickly, but I'm not sure I believe it.
 225 17:52:40 <garyo-home>	LIBS.
 226 17:52:56 <garyo-home>	I know Nodes work, not sure about abs paths.
 227 17:53:01 <GregoryNoel>	And what if it begins C: ?
 228 17:53:09 <stevenknight>	I don't think abs paths work
 229 17:53:18 <GregoryNoel>	I don't either
 230 17:53:19 <stevenknight>	I think strings all just get a -l prepended (on Linux)
 231 17:53:20 <garyo-home>	ok, I defer to you.
 232 17:53:36 <garyo-home>	In which case what's the bug?
 233 17:53:44 <GregoryNoel>	invalid
 234 17:54:04 <stevenknight>	You can say env.Program('#foo.c', LIBS=['#bar.lib'])
 235 17:54:16 <stevenknight>	and the target gets interpreted into a Node
 236 17:54:18 <stevenknight>	and the LIBS doesn't
 237 17:54:23 <GregoryNoel>	and the first is a file and the second is the name of a lib
 238 17:54:26 <stevenknight>	and that looks inconsistent to users
 239 17:54:40 <garyo-home>	Steven: but File('#bar.lib') does.  I think it's correct as is.
 240 17:54:42 <stevenknight>	if it's only for the name of a lib then why can you use a Node therE?
 241 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.
 242 17:55:19 <stevenknight>	exactly
 243 17:55:23 <garyo-home>	So you have a point.
 244 17:55:38 <GregoryNoel>	Why doesn't File(#name) work?
 245 17:55:52 <stevenknight>	it does
 246 17:55:53 <garyo-home>	Greg: because typically name is in LIBPATH, not here.
 247 17:56:02 <stevenknight>	but why do you have to specify File() for the target and not the LIBS?
 248 17:56:19 <GregoryNoel>	because it's a library name
 249 17:56:29 <stevenknight>	then why does a Node work there?
 250 17:56:45 <garyo-home>	special dispensation, escape hatch.
 251 17:56:47 <stevenknight>	okay, ta,e this out of LIBS
 252 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
 253 17:57:19 <stevenknight>	should this behave the same as CPPPATH?
 254 17:57:34 <garyo-home>	Does it?
 255 17:57:43 <stevenknight>	i'm not sure, actually  :-)
 256 17:58:01 <GregoryNoel>	if it ends in PATH, it's a list of file locations; they have Node() applied automatically
 257 17:58:15 <garyo-home>	It's *slightly* different because libs typically have pre and suffixes, and you specify them without those.
 258 17:58:21 <stevenknight>	we do have a test for absolute paths w/CPPPATH, so it looks like that works
 259 17:59:04 <stevenknight>	and we have tests for '#' as well, so that works
 260 17:59:17 <stevenknight>	true re: prefixes and suffixes
 261 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?
 262 18:00:22 <garyo-home>	(sorry, not by looking on any path)
 263 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 #
 264 18:00:42 <stevenknight>	well, now I'm going to play devil's advocate and argue with myself
 265 18:01:02 <stevenknight>	because that does open up the can of worms about where on the slippery slope we draw the line
 266 18:01:13 <stevenknight>	which I think might be underlying Greg's concern about this
 267 18:02:17 <GregoryNoel>	YES
 268 18:01:54 <garyo-home>	I'd be comfortable with abs paths; no existing lib could have such a name.
 269 18:02:12 <stevenknight>	yeah, abs paths, and '#'
 270 18:02:34 <stevenknight>	i'm kind of bugged by the fact that LIBS=['foo.lib'] gets turned into '-lfoo.lib'
 271 18:02:44 <garyo-home>	The suffix problem
 272 18:02:48 <stevenknight>	but I don't know how to avoid that without getting really hairy about suffixes
 273 18:02:49 <stevenknight>	yes
 274 18:03:08 <garyo-home>	right, what if they really wanted foo.lib.lib
 275 18:03:26 <garyo-home>	or whatever
 276 18:03:26 <GregoryNoel>	You begin to see the issue
 277 18:03:27 <stevenknight>	exactly
 278 18:03:42 <stevenknight>	so I'm not unsympathetic to both sides
 279 18:03:51 <garyo-home>	but that's a different issue, right?  We're only talking about / and # and maybe C:/
 280 18:04:24 <GregoryNoel>	I say stick to your guns, keep it simple
 281 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.
 282 18:04:43 <GregoryNoel>	and don't start down the slippery slope
 283 18:04:58 <GregoryNoel>	not with /, not with #, and not with C:
 284 18:05:56 <garyo-home>	Greg: be specific please?
 285 18:06:15 <GregoryNoel>	Huh?  I think the issue is INVALID
 286 18:06:27 <GregoryNoel>	it works exactly as it's supposed to work
 287 18:06:48 <GregoryNoel>	and we shouldn't be in the business of being too smart
 288 18:07:07 <GregoryNoel>	about what the user (luser?) is "trying" to do
 289 18:07:15 <david__>	Definitely
 290 18:07:29 <stevenknight>	even when not being smart means we end up confusing the user?
 291 18:07:38 <david__>	Many tools in python around build/distribition try to be smart, and fail miserably
 292 18:07:50 <GregoryNoel>	That's what the FAQ is for, and the mailing lists
 293 18:08:05 <GregoryNoel>	If there's really an issue, put it in the documentation
 294 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.
 295 18:08:37 <GregoryNoel>	Pretty clear to whom?
 296 18:08:44 <garyo-home>	the user.
 297 18:08:55 <garyo-home>	They don't want -l/foo/bar/baz.lib.
 298 18:09:21 <GregoryNoel>	I think you're likely to be correct, but somebody just might.
 299 18:10:13 <david__>	It is easier to find the workaround than understanding why it does not work in some cases because of 'magic'
 300 18:10:38 <GregoryNoel>	Instead of INVALID, how about changing the documentation to be clear about it?  With an example?
 301 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.
 302 18:10:52 <GregoryNoel>	File() in this case...
 303 18:11:06 <david__>	That sounds like the most reasonable thing to do to me
 304 18:11:11 <garyo-home>	OK.
 305 18:11:13 <stevenknight>	okay, hang on re: File()
 306 18:11:36 *	GregoryNoel is hanging....
 307 18:11:37 <stevenknight>	if you're going to use File() then you have to spell out everything
 308 18:11:43 <stevenknight>	which means you end up with things like:
 309 18:11:51 <garyo-home>	But you already are in these cases.
 310 18:12:12 <stevenknight>	LIBS = ['$LIBRARY_DIR/foo/${LIBPREFIX}bar{$LIBSUFFIX}')
 311 18:12:34 <GregoryNoel>	Huh?  Who ever said that?
 312 18:12:38 <stevenknight>	sorry, LIBS=[File('')]
 313 18:12:46 <stevenknight>	that's the real-world use case I'm working with right now
 314 18:12:56 <garyo-home>	right, you need the pre/suffixes for OS independence.
 315 18:13:29 <garyo-home>	But you were planning on passing a full pathname anyway, right?
 316 18:14:07 <GregoryNoel>	I see; File() doesn't interpolate the variables?  What about env.File()?
 317 18:14:07 <GregoryNoel>	hello?
 318 18:14:25 <stevenknight>	yes, env.File()
 319 18:14:40 <stevenknight>	sorry, I'm translating between a verbal argument and an IRC argument about this real time... :-)
 320 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)
 321 18:15:09 <stevenknight>	np
 322 18:15:16 <garyo-home>	ok.
 323 18:15:23 <stevenknight>	fair point about needing to specify the file name
 324 18:15:41 <david__>	If File does not interpolate, should it be done in File or a Lib subclass ?
 325 18:15:56 <stevenknight>	no, you use env.File(), which does interpolate
 326 18:15:58 <GregoryNoel>	In theory, env.File() should interpolate.  Doesn't it?
 327 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?
 328 18:15:59 <stevenknight>	i mistyped the first example
 329 18:16:07 <stevenknight>	no, i'm not
 330 18:16:29 <garyo-home>	greg: yes.
 331 18:16:38 <stevenknight>	okay, how about if we table this
 332 18:16:43 <stevenknight>	give it to me to research
 333 18:16:55 <GregoryNoel>	I'll agree
 334 18:16:59 <garyo-home>	ok.
 335 18:16:58 <stevenknight>	I'll kick around ideas here with the real-world sufferers
 336 18:17:17 <garyo-home>	:-)
 337 18:17:21 <stevenknight>	and we don't discuss it again until (or if) there's a tangible proposal for changing the behavior
 338 18:17:30 <stevenknight>	whew!
 339 18:18:16 <GregoryNoel>	Back to 2099?  (which we accidentally skipped?)
 340 18:18:48 <GregoryNoel>	Hello?
 341 18:19:07 <garyo-home>	Saw this on the ML. Steven understands it. I think should be fixed soon; it's a regression.
 342 18:19:10 <garyo-home>	1.0.x, p2.
 343 18:19:30 <GregoryNoel>	works for me
 344 18:19:31 <stevenknight>	done
 345 18:19:43 <GregoryNoel>	2101: Consider a Solaris system with the Sun C compiler installed but without GCC installed.
 346 18:19:43 <GregoryNoel>	There are three Tools specified for the C compiler: ['aixcc', 'gcc', 'cc']
 347 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.
 348 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.
 349 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.
 350 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.
 351 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().
 352 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.
 353 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.
 354 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.
 355 18:19:43 <GregoryNoel>	(Or to "tools=['mingw','default','mingw'] so it works either way.)
 356 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").
 357 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).
 358 18:19:43 <GregoryNoel>	I'm torn.  I feel the documented semantics are the right choice, but it would be a _big_ disruption.
 359 18:20:21 <stevenknight>	damn, Greg, your typing sure got fast all of a sudden!
 360 18:20:32 <stevenknight>	:-)
 361 18:20:35 <garyo-home>	rofl
 362 18:20:59 <GregoryNoel>	I practiced all week {;-}
 363 18:21:51 <david__>	Concerning tools, my impression is that people who need some control just do it manually, no ?
 364 18:22:00 <stevenknight>	ah, I didn't realize we're incompatible with our own doc
 365 18:22:39 <GregoryNoel>	Yes, we seem to be able to apply two different models simultaneously
 366 18:23:04 <david__>	What is the documented semantics ?
 367 18:23:12 <david__>	What are, sorry
 368 18:23:26 <david__>	The one in scons man, or in the code ?
 369 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
 370 18:24:06 <stevenknight>	("Doc, it hurts when I do this."  "Well, don't do that.")
 371 18:24:06 <GregoryNoel>	The man page says that the first-listed applies.  The code says that _all_ are applied.
 372 18:24:33 <stevenknight>	whoa, wait, I think you're looking at two different lists...?
 373 18:24:55 <GregoryNoel>	(In fact, I don't know why it fails.  It should just be generated twice.)
 374 18:25:25 <garyo-home>	From the stacktrace, the generate doesn't fail, it fails while compiling cause something gets busted.
 375 18:25:28 <GregoryNoel>	What two different lists?
 376 18:25:46 <stevenknight>	oh, wait, I'm sorry, I thought you were thinking of the preferences in Tool/
 377 18:26:13 <garyo-home>	I'm trying to find the man page doc for this & failing.  Greg?
 378 18:26:29 <stevenknight>	where does it say only the first is applied?
 379 18:26:30 <GregoryNoel>	That may be another bug, not related
 380 18:26:52 <david__>	I don't remember having seen this either ? I thought scons manual said the last one is applied ?
 381 18:27:14 <stevenknight>	oh, shoot, I hate to be late to the party *and* leave early
 382 18:27:16 <GregoryNoel>	Hmmm...  Doesn't it say that local compilers are chosen over FOSS toolchains?
 383 18:27:17 <garyo-home>	I don't see anything about lists of tools there.
 384 18:27:19 <stevenknight>	but I'm still at work and taking the late shuttle
 385 18:27:26 <stevenknight>	so I have to leave and get over to the stop
 386 18:27:34 <garyo-home>	Yes, but nothing about lists.
 387 18:27:55 <stevenknight>	I'll connect again once I'm there in case anyone's still going
 388 18:28:00 <stevenknight>	but don't feel obligated on my account
 389 18:28:02 <garyo-home>	Closest is the MingW section.
 390 18:28:05 <stevenknight>	later
 391 18:28:09 <garyo-home>	bye
 392 18:28:09 *	stevenknight has quit ("Leaving")
 393 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.
 394 18:29:43 <GregoryNoel>	I'm not finding any obvious keywords, but then I'm a terrible searcher.
 395 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."
 396 18:30:36 <GregoryNoel>	That's not what's reflected in the code.
 397 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.
 398 18:30:51 <GregoryNoel>	works for me
 399 18:31:26 <GregoryNoel>	let Steven research whether there's a different bug in play that's tickled by re-applying mingw
 400 18:31:42 <garyo-home>	good.
 401 18:32:25 <GregoryNoel>	2102, stevenknight, VisualStudio?
 402 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.
 403 18:32:37 <garyo-home>	agreed.
 404 18:32:37 <GregoryNoel>	concur
 405 18:32:43 <david__>	Argh, I should have asked Steven
 406 18:32:48 <david__>	I have the code for this
 407 18:33:07 <david__>	parsing vsvarsall.bat also makes possible cross compilation to x64, in theory
 408 18:33:41 <GregoryNoel>	He has the code, yes?
 409 18:33:41 <garyo-home>	david__: yes.  Please post your code on the dev list if you can.  And you're right, it also solves issue 2013.
 410 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
 411 18:34:07 <garyo-home>	sorry, yes 2103 not 2013
 412 18:34:07 <david__>	@gary: the only reason why I did not post the code publicly is because of licensing
 413 18:34:16 <david__>	But that may be red-herring
 414 18:34:34 <david__>	I don't understand the difference between python license and scons (MIT) license
 415 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?
 416 18:34:41 <GregoryNoel>	If there could be a licensing issue, we can't look at it.
 417 18:35:22 <GregoryNoel>	MIT license is more liberal, has fewer restrictions.
 418 18:35:37 <GregoryNoel>	IANAL, but I believe they're compatible.
 419 18:35:34 <david__>	@Greg: my code is inspired by distutils. But the code is a rewrite. What shall I do ?
 420 18:35:59 <david__>	(I did not get answer from the original commiter in distutils)
 421 18:35:59 <garyo-home>	If it's a rewrite I think we are safe enough.
 422 18:36:05 <david__>	It is
 423 18:36:12 <GregoryNoel>	If you wrote it, pretty much from scratch, it's yours to assign as you choose
 424 18:36:14 <david__>	Variable are different, functions are different
 425 18:36:36 <david__>	Parsing is different, too
 426 18:36:51 <garyo-home>	That seems pretty clear that it's your work, not derived.
 427 18:36:53 <GregoryNoel>	Probably (IANAL) good enough
 428 18:37:04 <garyo-home>	Just inspired.  But IANAL either...
 429 18:37:19 <david__>	Inspired and derivative can only be decided in court, right ?
 430 18:37:26 <garyo-home>	:-/
 431 18:37:34 <GregoryNoel>	unfortunately
 432 18:37:46 <david__>	I don't see python developer assigning me to court, though
 433 18:37:56 <garyo-home>	No I think you're right.
 434 18:38:12 <GregoryNoel>	Since they'd have to bring action in France or Japan, I doubt it
 435 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
 436 18:38:52 <david__>	and if the .bat is not found, I read the VS*COMMON fenv variable
 437 18:39:03 <david__>	Since I can check for the existence of a file
 438 18:39:11 <david__>	even stalled registry keys do not break things
 439 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.
 440 18:39:32 <david__>	I am not a windows programmer
 441 18:39:37 <garyo-home>	I am.
 442 18:39:42 <david__>	good
 443 18:39:53 <david__>	So shall I consider the code to be safe to put in scons svn ?
 444 18:40:03 <david__>	Shall I wait for Steven answer, maybe ?
 445 18:40:13 <GregoryNoel>	Nag him
 446 18:40:19 <david__>	Ok
 447 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.
 448 18:40:48 <GregoryNoel>	Does that get us to 2104?
 449 18:40:54 <garyo-home>	I think so.
 450 18:41:10 <david__>	The easy fix is easy :)
 451 18:41:31 <garyo-home>	Is there any risk?  Does it change the user command line?
 452 18:41:33 <david__>	But this can be done in a common module between msvc and posix C compilers ?
 453 18:41:45 <GregoryNoel>	I suspect it's a real defect from the fix for CCFLAGS,
 454 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
 455 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.
 456 18:43:04 <garyo-home>	Of course (devil's advocate) if it's going to cause recompiles, maybe better now than later.
 457 18:43:25 <GregoryNoel>	Steven says 1.0.x, I say 1.0; either way, immediately
 458 18:44:02 <garyo-home>	OK, fine w/ me. p3 or p4.
 459 18:44:15 <GregoryNoel>	which?  I'll go with 1.0.x
 460 18:44:30 <david__>	I don't understand why we should not change buggy behavior, which is also not consistent with documentation ?
 461 18:45:02 <GregoryNoel>	We should, but we don't want to take chances with disrupting what's working now
 462 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.
 463 18:45:20 <GregoryNoel>	so 1.0.x p3?
 464 18:45:25 <garyo-home>	ok.
 465 18:45:28 <GregoryNoel>	done
 466 18:45:34 <GregoryNoel>	When shall we all meet again?
 467 18:45:34 <GregoryNoel>	In thunder, lightning, or in rain?
 468 18:45:34 <GregoryNoel>	Where the place? ...
 469 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.
 470 18:45:58 <david__>	@Gary: understood.
 471 18:46:05 *	stevenknight (n=stevenkn@ has joined #scons
 472 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.
 473 18:46:23 <stevenknight>	hey there, anyone still around from the bug party?
 474 18:46:26 <stevenknight>	oh, there you go
 475 18:46:28 <garyo-home>	Hi Steven, we're talking about schedule for next wk.
 476 18:46:37 <david__>	For me, this time is fine
 477 18:46:48 <david__>	sooner is ... too soon
 478 18:47:10 <garyo-home>	Time's good w/ me.  Monday is the usual day; that OK?
 479 18:47:10 <stevenknight>	garyo-home:  a different time would help?
 480 18:47:23 <stevenknight>	Monday's fine with me
 481 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.
 482 18:47:49 <david__>	same time ?
 483 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 :-/
 484 18:48:44 <david__>	Same time as now would be fine for me
 485 18:48:52 <david__>	if it is more convenient for you
 486 18:48:54 <stevenknight>	okay, same time Monday next week
 487 18:48:58 <GregoryNoel>	Now == noon?
 488 18:49:08 <david__>	For me, now is 10:30 a.m
 489 18:49:30 <GregoryNoel>	(doing arithmetic in head) Ah, yes
 490 18:49:34 <david__>	There is 14 hours difference with West Coast if I remember right
 491 18:49:52 <GregoryNoel>	you're UTC+9
 492 18:50:03 <david__>	Yes
 493 18:50:03 <stevenknight>	where?
 494 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)
 495 18:50:10 <GregoryNoel>	Japan
 496 18:50:21 <stevenknight>	ah
 497 18:50:22 <GregoryNoel>	Er, Nippon
 498 18:50:24 <garyo-home>	i.e. start around now
 499 18:50:36 <garyo-home>	Steven, what about you?
 500 18:50:36 <david__>	now is fine by me
 501 18:51:03 <stevenknight>	this time works well, but i'm pretty flexible
 502 18:51:14 <GregoryNoel>	it's 18h30 or 19 o'clock for us; it would work for me
 503 18:51:16 <stevenknight>	now is fine too
 504 18:51:26 <david__>	I am a student, so I am the most flexible one I guess :)
 505 18:51:35 <stevenknight>	actually, the shuttle usually drops me at 18h30 and i have a 15 min walk
 506 18:51:40 <stevenknight>	18h45?
 507 18:51:51 <GregoryNoel>	19 o'clock?
 508 18:52:00 <stevenknight>	19h00 is okay with me
 509 18:52:04 <stevenknight>	gary, does that work for you?
 510 18:52:21 <stevenknight>	that's 22h00 for you, after kids are in bed but maybe getting late...?
 511 18:52:22 <GregoryNoel>	Monday or Tuesday?
 512 18:52:22 <garyo-home>	Yes, fine.  That's 2200 for me, or 1600GMT?
 513 18:52:27 <stevenknight>	yes
 514 18:52:28 <garyo-home>	Monday ok?
 515 18:52:43 <garyo-home>	Steven: no problem, I stay up late sometimes anyway
 516 18:52:51 <GregoryNoel>	No, 0200 UTC, I think
 517 18:53:05 <garyo-home>	greg: sorry, you're right of course
 518 18:53:13 <GregoryNoel>	(Always!)
 519 18:53:51 <stevenknight>	:-)
 520 18:53:58 <david__>	monday in the US is fine for me
 521 18:54:03 <GregoryNoel>	OK, I'll update the bug party page before I go for Monday at 19 o'clock PDT
 522 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.
 523 18:54:13 <stevenknight>	great, thanks
 524 18:54:42 <GregoryNoel>	I guess that's it, and dinner calls.  Later.
 525 18:54:47 <stevenknight>	i'll prep next week's spreadsheet(s) and send out announcements
 526 18:54:50 <garyo-home>	greg: have fun on vacation!
 527 18:54:57 <GregoryNoel>	wilco
 528 18:54:57 <stevenknight>	have a good time
 529 18:55:05 <david__>	Steven: we were discussing visual studio revamp, and I was wondering what you think about license issues ?
 530 18:55:23 <stevenknight>	license for...?
 531 18:55:25 <stevenknight>	SCons code?
 532 18:55:33 <david__>	Did you see the email I sent you last WE ?
 533 18:55:38 <garyo-home>	he's talking about reading vsvars.bat
 534 18:55:43 <garyo-home>	he has some good code
 535 18:55:48 <stevenknight>	it's probably buried -- hang on, i can check
 536 18:55:52 <david__>	well, I don't know if it is good
 537 18:56:01 <david__>	but it is a start at least
 538 18:56:21 <david__>	@steven: basically, the code started as a derivative of some code in distutils
 539 18:56:27 <david__>	but it is a rewrite now
 540 18:56:40 <stevenknight>	oh, right, now i remember
 541 18:56:47 <david__>	I did not get an answer from the original comiter in python svn
 542 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 ?
 543 18:57:33 <stevenknight>	i think in practice it's okay
 544 18:57:34 <david__>	but I don't want to cause any trouble
 545 18:57:49 <stevenknight>	i definitely appreciate that
 546 18:57:59 <stevenknight>	I'd say go ahead with it
 547 18:58:05 <stevenknight>	especialy since it's largely a rewrite now
 548 18:58:09 <david__>	ok, I will start a branch, then
 549 18:58:24 <stevenknight>	as you say, since the origin is open source, it's pretty unlikely to cause trouble
 550 18:58:29 <david__>	Yes: different variables, different function names and code in functions (I support older versions of VS)
 551 18:58:38 <stevenknight>	and if it does they can sue us for the $200 or so in the SCons bank account... :-)
 552 18:58:57 <david__>	Shall I say in the comments it is inspired by distutils ?
 553 18:59:19 <stevenknight>	I think it's courteous to do so
 554 18:59:28 <david__>	I think so too
 555 18:59:35 <garyo-home>	yes me too.
 556 18:59:35 <david__>	Ok, will commit to a new branch, then
 557 18:59:55 <garyo-home>	I am psyched to try this out!
 558 19:00:04 <david__>	Well, there is really nothing fancy
 559 19:00:19 <garyo-home>	That's extremely good.  The current version is way too fancy!
 560 19:00:21 <david__>	but this method, I understand. The original one with registry, I don't
 561 19:00:38 <stevenknight>	david__:  are you using bzr or some other interface to svn?
 562 19:00:44 <garyo-home>	nobody does anymore, it evolved from a nice simple idea into a Microsoft-inspired mush.
 563 19:00:57 <david__>	Gary, since you are familiar with windows, do you know what happens if VS is installed in a different directory ?
 564 19:01:09 <david__>	I would guess the registry key is changed accordingly
 565 19:01:21 <david__>	but the registry is such a POS that I never know what to expect
 566 19:01:37 <david__>	@steven: not for scons, but yes, I sometimes do. Why ?
 567 19:02:00 <stevenknight>	just curious
 568 19:02:15 <garyo-home>	Yes, some registry will be different.
 569 19:02:39 <stevenknight>	i like that you do your work on the branches
 570 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
 571 19:02:58 <david__>	Thanks, gary
 572 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
 573 19:03:24 <david__>	Well, I never understood svn. bzr is the first source control system that made sense to me
 574 19:03:46 <stevenknight>	i'm very interested in moving us to bzr
 575 19:04:05 <stevenknight>	we were talking about moving hosting to launchpad for that, but it's not really mature enough
 576 19:04:07 <david__>	The problem with bzr is launchpad
 577 19:04:12 <david__>	There are some good things
 578 19:04:17 <david__>	but way too complicated
 579 19:04:32 <david__>	and there is no good developer documentation
 580 19:04:51 <stevenknight>	yeah, seemed like too much is really opaque
 581 19:04:56 <david__>	I would really like to be able to do most of the tasks from the command line.
 582 19:05:08 <stevenknight>	command line++
 583 19:05:12 <david__>	For example, submitting/commenting bugs
 584 19:05:31 <david__>	But also control release, series, upload of tarballs
 585 19:05:44 <stevenknight>	agreed
 586 19:05:47 <david__>	For bugs, there is a xmlrpc thing
 587 19:05:58 <david__>	bug I don't know anything about those technologies
 588 19:06:12 <stevenknight>	right now i'm thinking about
 589 19:06:34 <garyo-home>	cool idea!
 590 19:06:36 <stevenknight>	which is svn, but maybe use bzr as the standard frontend
 591 19:06:45 <stevenknight>	yeah, at first I thought it didn't have what we want
 592 19:06:54 <stevenknight>	but it's actually got a pretty good bug tracker, and a wiki built in
 593 19:07:13 <garyo-home>	I just used google data 1st time last night, very smooth & easy.. Do these use the same APIs?
 594 19:07:14 <david__>	@steven: I am not sure I would recommend it (bzr as a frontend with svn backend)
 595 19:07:31 <stevenknight>	not quite all the features we need in the bug tracker, though -- no date-range searches
 596 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.
 597 19:08:17 <stevenknight>	i'm not 100% sure about google data + code.
 598 19:08:24 <garyo-home>	Integrated wiki, milestones, tickets, log browser, source browser.
 599 19:08:41 <stevenknight>	but there's pretty good integration in a lot of the google stuff
 600 19:08:49 <david__>	I don't like trac either
 601 19:08:54 <stevenknight>	so it'll probably happen some day if it's not already available
 602 19:09:03 <david__>	trac+bzr is not a good idea
 603 19:09:03 <garyo-home>	And google's behind it which is important!
 604 19:09:13 <stevenknight>	yep!
 605 19:09:21 <david__>	if bzr is chosen, then launchpad is pretty much the only choice ATM
 606 19:09:24 <garyo-home>	david: I've heard the same from others.  Not ready for prime time yet.
 607 19:09:37 <garyo-home>	What about other dvcses?
 608 19:09:39 <stevenknight>	david__:  what problems have you had/heard about with bzr+svn?
 609 19:09:51 <david__>	Well, first, it is difficult to install
 610 19:10:05 <david__>	Because python wrappers around svn are buggy
 611 19:10:11 <stevenknight>	i have to disconnect and switch buses, will reconnect right away
 612 19:10:14 <garyo-home>	... and being a plugin it's a 2nd class citizen.
 613 19:10:32 <david__>	@gary: I have some limited experience with mercurial and git
 614 19:10:42 <david__>	I am not aware of any bug tracking system with mercurial
 615 19:10:51 <david__>	git is without any question the most powerful
 616 19:10:56 <david__>	it is pretty amazing
 617 19:11:01 <david__>	but can be complicated
 618 19:11:15 <garyo-home>	what's complicated?  Simple things, or complicated things?
 619 19:11:18 <david__>	and I don't know its status on windows 
 620 19:11:26 <david__>	The nature of the tool is complicated
 621 19:11:30 <garyo-home>	i see.
 622 19:11:45 <david__>	For example, if you do git add and git commit, it will not add anything
 623 19:11:58 <david__>	also, git (and mercurial) do have multi branch in a tree
 624 19:12:05 <garyo-home>	Was there some talk of wrappers to simplify it?
 625 19:12:06 <david__>	Which is arguably more powerful sometimes
 626 19:12:12 <david__>	bzr, with one branch is one directory
 627 19:12:17 <david__>	is definitely simpler
 628 19:12:30 <garyo-home>	yes, less mental bookkeeping
 629 19:12:36 <david__>	Another key difference between bzr and git/mercurial is the mainline concept
 630 19:12:47 <david__>	in bzr, when you merge a branch into another one
 631 19:12:56 <david__>	the history is not flat
 632 19:13:09 <david__>	which bugs git/mercurial users
 633 19:13:30 <david__>	But has a great advantage: you can guarantee that every commit of the mainline is correct (pass test, etc...)
 634 19:13:48 <david__>	I feel that bzr fits more the way scons development works
 635 19:13:58 <david__>	but I am not that familiar with scons development yet
 636 19:14:03 <stevenknight>	hey, looks like i went from bus to bus without having to drop the irc connection...
 637 19:14:07 <stevenknight>	cool
 638 19:14:09 <garyo-home>	makes sense.  Maybe we just keep thinking about it for a while.
 639 19:14:37 <garyo-home>	Maybe launchpad will get better, or will support bzr as a front end.
 640 19:14:48 <david__>	I think the choice really is DVCS+tracker
 641 19:14:56 <david__>	you could choose independently
 642 19:15:01 <david__>	but in practice, you can't
 643 19:15:11 <garyo-home>	I think you're right.
 644 19:15:22 <david__>	Well, you can't if you want free hosting, at least
 645 19:15:51 <david__>	I will try, too. Which is open source
 646 19:16:11 <david__>	gitorious, sorry. Github is commercial, the one user by RoR
 647 19:16:37 <stevenknight>	well, if we do go with, the silver lining would not having to change the underlying SCM
 648 19:16:55 <garyo-home>	Steven: with google, would it have to be "Google SCons"? :-)
 649 19:17:03 <david__>	What are the advantages of google code ?
 650 19:17:04 <stevenknight>	LOL
 651 19:17:17 <david__>	You are at google, right, steven ?
 652 19:17:28 <stevenknight>	there sems to be a path where things start out being named "google X" and then eventually get shortened
 653 19:17:32 <stevenknight>	yes, i'm at google now
 654 19:17:50 <stevenknight>	that's one reason to look more closely at, but not the most important one
 655 19:18:09 <stevenknight>	i'm more interested in making sure we get a good development process, regardless of where it's hosted
 656 19:18:11 <david__>	Personally, I am more interested in changing the source control system than the ticket system
 657 19:18:25 <garyo-home>	+1
 658 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)
 659 19:19:37 <garyo-home>	for us (non open source, proprietary code), a centralized vcs makes much more sense and keeps things simple.
 660 19:19:39 <stevenknight>	i didn't realize people were still arguing that svn is better than the DVCSs out there
 661 19:19:59 <garyo-home>	For a distributed project, nobody could argue in favor of svn!
 662 19:20:08 <stevenknight>	right
 663 19:20:38 <david__>	@Gary: but git and bzr can have a centralized VCS
 664 19:20:53 <stevenknight>	garyo:  have you seen Linus Torvald's talk at Google where he trashes svn?
 665 19:21:06 <garyo-home>	yes, but for us it wouldn't gain us much.  Steven: yes, the famous talk.
 666 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
 667 19:21:40 <garyo-home>	you're both right, and I'll migrate GenArts (my company) to a dvcs probably in 18 months - 2 years.
 668 19:21:43 <stevenknight>	actually, i took away from that talk one very important thing about SCons (by analogy)
 669 19:22:12 <stevenknight>	i really like his point that by making branching O(1), svn was optimizing the wrong thing
 670 19:22:22 <stevenknight>	because that's done so much less than merging
 671 19:22:44 <david__>	yes. Nobody does merging with svn. It does not work
 672 19:22:44 <garyo-home>	so true!
 673 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
 674 19:23:02 <garyo-home>	We have a workflow that does work, but it is highly restricted.
 675 19:23:27 <garyo-home>	steven: I see what you're getting at.  Incremental builds are done 100x/day, full builds rarely.
 676 19:23:36 <stevenknight>	right
 677 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
 678 19:24:02 <stevenknight>	but everyone notices the incremental slowdown
 679 19:24:20 <garyo-home>	True.  Subdir builds can help some.
 680 19:24:30 <david__>	What are the plans for 1.0 and after ?
 681 19:24:43 <david__>	I mean, what's missing for 1.0 ?
 682 19:24:49 <stevenknight>	nothing
 683 19:25:05 <stevenknight>	we're just letting 0.98.5 cook a little more while we write doc
 684 19:25:15 <stevenknight>	it'll become 1.0
 685 19:25:27 <stevenknight>	and then we argue about how soon to branch for 2.0  :-)
 686 19:25:38 <stevenknight>	i'm actually with Bill Deegan, I want to move on to 2.0 quickly
 687 19:25:39 <garyo-home>	hey guys, have to go.  See you next Monday.
 688 19:25:45 <stevenknight>	2.0 drops compatibility with 1.5.2
 689 19:25:52 <stevenknight>	thanks gary -- catch you later
 690 19:25:58 <stevenknight>	Python 1.5.2, that is
 691 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)
 692 19:26:07 <david__>	see you
 693 19:26:26 <stevenknight>	So SCons 2.0 will be written to work on Python 2.2 and later
 694 19:26:32 <david__>	great
 695 19:26:47 <david__>	to me, that's one of the main showstopper
 696 19:26:44 <stevenknight>	that lets us git rid of all sorts of map() and filter() calls in favor of list comprehensions
 697 19:26:51 <stevenknight>	which should speed up a lot of stuff
 698 19:26:58 <david__>	Getting rid of eval is more important IMO
 699 19:26:58 <stevenknight>	understood
 700 19:27:19 <david__>	Because it makes the code difficult to profile
 701 19:27:23 <david__>	and to understand
 702 19:27:25 <stevenknight>	so it can be run with psyco?
 703 19:27:31 <stevenknight>	ah
 704 19:27:34 <david__>	This, I don't know
 705 19:27:40 <david__>	But I know scons is difficult to profile
 706 19:28:06 <stevenknight>	hmm, i didn't think eval() was that much of an issue for profiling
 707 19:28:16 <stevenknight>	where is it getting in the way for you?
 708 19:28:18 <david__>	You don't know what's executed ?
 709 19:28:47 <stevenknight>	but we're not doing that much eval'ing, except in string substituion when ${} is used
 710 19:28:48 <david__>	With cProfile, at least (python profile is useless for big projects)
 711 19:28:50 <stevenknight>	is that what you're referring to?
 712 19:28:53 <david__>	no
 713 19:28:59 <david__>	let me check
 714 19:29:44 <stevenknight>	BTW re: cProfile: how do its results compare with python profile?
 715 19:29:54 <david__>	It is much faster
 716 19:29:57 <stevenknight>	does it give exactly the same, or are you comparing apples-and-oranges
 717 19:30:03 <stevenknight>	that's it's execution speed
 718 19:30:16 <stevenknight>	what about the code it's measuring?
 719 19:30:22 <david__>	The problem with profile is that for example a noop build is like 10 times slower
 720 19:30:30 <david__>	so it is basically useless
 721 19:30:59 <david__>	so much overhead that it is measuring a totally different thing that what you run normally
 722 19:31:21 <david__>	For example, I build lapack with scons. Lapack is an old fortran library: one function per file, 2000 files
 723 19:31:37 <david__>	a No op build is taking 10 seconds. But with python profile, it is taking 2 minutes IIRC
 724 19:31:54 <david__>	So you are not really measuring the same thing.
 725 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
 726 19:32:46 <stevenknight>	is the code execution they're measuring determinstic such that I can meaningfully compare python profile results with cProfile results?
 727 19:32:58 <david__>	I am not sure
 728 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?
 729 19:33:25 <stevenknight>	right, that's my dilemma
 730 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
 731 19:34:07 <david__>
 732 19:34:34 <david__>	They say they are interchangeable, but they only talk about the API
 733 19:34:42 <stevenknight>	right
 734 19:35:12 <david__>	One problem kind of specific to scons
 735 19:35:19 <david__>	is that it is using a lot of functions
 736 19:35:32 <david__>	which is extremely slow with python; and python profile makes it much slower
 737 19:35:52 <david__>	I guess this is the main problem with python profile
 738 19:36:02 <stevenknight>	yes
 739 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
 740 19:36:49 <stevenknight>	right now one of the big killers is the scanning of directories like CPPPATH
 741 19:36:59 <stevenknight>	directory paths, i should say
 742 19:37:18 <stevenknight>	there's basically a O(n^2) algorithm in there that explodes the function call counts
 743 19:37:32 <david__>	T. Nagy also said that "compiling" actions strings to functions speeds things a lot
 744 19:37:36 <stevenknight>	i think we can make the path search O(1)
 745 19:37:47 <stevenknight>	that makes sense
 746 19:37:50 <david__>	Is this something doable ?
 747 19:38:01 <stevenknight>	yes, i think so
 748 19:38:04 <david__>	There are some things which are much faster in waf, and I don't see why scons is slower
 749 19:38:13 <david__>	for configuration checks, for example
 750 19:38:29 <stevenknight>	i have a half-finished re-implementation of that separates the string parse from the expansion
 751 19:38:34 <stevenknight>	right now we do both every time
 752 19:38:38 <stevenknight>	that might be in the same direction
 753 19:39:03 <stevenknight>	more and more i'm finding that our slowness is dumb implementatiions
 754 19:39:07 <stevenknight>	not so much incorrect ideas
 755 19:39:12 <david__>	Would having scons as a python library possible at all ?
 756 19:39:15 <david__>	Well, that's good.
 757 19:39:19 <stevenknight>	things that grew over time in ways not originally envisioned
 758 19:39:23 <david__>	It means if is fixable
 759 19:39:29 <david__>	it is fixable, sorry
 760 19:39:35 <stevenknight>	so far i haven't found anything that doesn't look fixable
 761 19:39:49 <stevenknight>	do you mean scons as a standard python library?
 762 19:40:17 <david__>	yes
 763 19:40:28 <david__>	I am afraid this would be extremely complicated
 764 19:40:36 <stevenknight>	probably
 765 19:40:41 <david__>	but this would be a killer.
 766 19:40:56 <stevenknight>	the topic came up very briefly at a SCons BOF with Guido and Alex several years ago
 767 19:40:57 <david__>	Ok, I was wrong, as I expected: I was talking about apply, not eval
 768 19:41:21 <stevenknight>	Guido sounded skeptical, i think because SCons seems too application-specific
 769 19:41:23 <david__>	People in numpy/scipy were also a bit afraid of that, when I started using it to build numpy/scipy
 770 19:41:36 <stevenknight>	it's hard to see it as a generic library that people want to re-use in different contexts
 771 19:41:40 <david__>	I think the general ideas make a lot of sense
 772 19:41:47 <stevenknight>	yes re: the over-use of apply()
 773 19:41:56 <david__>	build/distribution is really a big PITA in python right now
 774 19:42:05 <stevenknight>	yes!
 775 19:42:25 <stevenknight>	and so-called "easy" install only complicated things for packagers, in my view...
 776 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)
 777 19:42:58 <david__>	Don't get me started with setuptools :)
 778 19:43:20 <stevenknight>	right, I've been adopting more and more functional programming idioms over time
 779 19:43:26 <stevenknight>	and apply() is how you do that in 1.5
 780 19:43:42 <stevenknight>	so all of those can get turned into list comprehensions once we get 1.0 out the door
 781 19:43:58 <stevenknight>	or, heck, should just be turned into loops if that's more efficient
 782 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
 783 19:44:29 <david__>	it is like lambda
 784 19:44:42 <david__>	maybe dtrace can be smart about that, never tried.
 785 19:45:36 <david__>	Ok, I am starting the vs_revamp branch
 786 19:46:09 <stevenknight>	cool
 787 19:46:39 <stevenknight>	does there seem to be much (if any) work going into bzr-svn to make it more viable?
 788 19:47:00 <david__>	If you don't care about branches
 789 19:47:04 <david__>	then it is usable
 790 19:47:08 <david__>	but slow
 791 19:47:21 <david__>	which should not matter much for scons, though
 792 19:47:52 <stevenknight>	hmm, not caring about branches seems to lose one of the big advantages of a DVCS...
 793 19:48:17 <david__>	the problem is the svn backend
 794 19:48:28 <david__>	git-svn does not deal that well either
 795 19:48:35 <stevenknight>	ah
 796 19:48:37 <david__>	you can do bzr branch on svn repositories
 797 19:48:47 <david__>	but honestly...
 798 19:48:57 <david__>	I don't do it
 799 19:49:04 <david__>	For numpy/scipy, I create the branches by hand
 800 19:49:08 <david__>	with svn
 801 19:50:23 <stevenknight>	makes sense
 802 19:50:27 <david__>	Would it make sense to use google code with something else for code repository ?
 803 19:50:47 <stevenknight>	possibly
 804 19:51:00 <stevenknight>	i certainly don't think they care if you only use parts of the hosting service
 805 19:51:31 <stevenknight>	my bus stop is coming up soon
 806 19:51:34 <david__>	I meant from a practical POV
 807 19:51:48 <stevenknight>	not sure how well that would work in practice
 808 19:52:01 <stevenknight>	curious:  have you been in Japan long?
 809 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 ?
 810 19:52:26 <david__>	4 years
 811 19:52:36 <david__>	2 years working, 2 years of PhD so far
 812 19:52:39 <stevenknight>	re: git hosting, that would be fine
 813 19:52:55 <stevenknight>	my brother was in Tokyo for many years; his wife is Japanese
 814 19:53:08 <david__>	Oh
 815 19:53:14 <david__>	Never lived in Tokyo
 816 19:53:33 <stevenknight>	have to leave the bus now -- good chating w/you
 817 19:53:39 <david__>	If going into academia does not go as I want, I am thinking about trying working at Google in Tokyo :)
 818 19:53:39 *	stevenknight has quit ("Leaving")
 819 20:19:31 *	david__ has quit ("Leaving")
 820 20:28:56 *	garyo-home has quit (Read error: 104 (Connection reset by peer))

BugParty/IrcLog2008-06-17 (last edited 2008-06-18 06:38:55 by ip68-7-77-81)