IrcLog2010 07 20

William Deegan edited this page Jan 14, 2016 · 2 revisions
16:50:31  *      Garyo (~[chatzilla@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com](mailto:chatzilla@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com)) has joined #SCONS 
16:55:03  *      jason_at_intel (~[chatzilla@185.sub-75-205-7.myvzw.com](mailto:chatzilla@185.sub-75-205-7.myvzw.com)) has joined #SCONS 
16:55:21  *      bdbaddog (~[bdeegan@adsl-71-131-10-196.dsl.sntc01.pacbell.net](mailto:bdeegan@adsl-71-131-10-196.dsl.sntc01.pacbell.net)) has joined #SCONS 
17:03:18  *      sgk (~sgk@nat/google/x-vdmoydnhvesvboyw) has joined #SCONS 
17:05:37  <[GregNoel](GregNoel)>     Are we ready to go? 
17:05:44  <Garyo>        i am 
17:05:47  <jason_at_intel>       Hi Steve, think we found the cause of the temp file issue 
17:05:53  <sgk>  ready when everyone else is 
17:05:54  <jason_at_intel>       I am ready 
17:05:57  <[GregNoel](GregNoel)>     1938 Gary took it 
17:05:57  <[GregNoel](GregNoel)>     1891 
17:06:06  <sgk>  i saw your mail, that sounds exactly like what's going on 
17:06:42  <Garyo>        1891? 
17:07:01  <[GregNoel](GregNoel)>     That's what's on the spreadsheet. 
17:06:56  <sgk>  sorry, that reply was to jason 
17:07:00  <jason_at_intel>       I think it just needs a fix to mslink 
17:07:08  <sgk>  jason, let's stick to the issue list and we can discuss the tempfile thing in turn 
17:07:21  <sgk>  or at the end if we haven't gotten to it 
17:07:17  <jason_at_intel>       yep 
17:07:27  <jason_at_intel>       so 1891 
17:07:34  <jason_at_intel>       I think we need to fix mslink.py 
17:07:41  <jason_at_intel>       and this will work 
17:08:12  <sgk>  that makes sense 
17:08:07  <Garyo>        Agree it can't be that hard.  Who has time?  Jason, would you like to take a crack at it? 
17:08:19  <jason_at_intel>       I would be happy to 
17:08:27  <Garyo>        2.1 p3 jason? 
17:08:33  <jason_at_intel>       I will try it out in the Parts mslink version 
17:08:53  <jason_at_intel>       that should be easy to map back to the SCons version 
17:09:10  <jason_at_intel>       since it just a new set of actions 
17:08:59  <sgk>  cool, thanks 
17:09:03  <sgk>  2.1 p3 jason sounds good to me 
17:09:06  <[GregNoel](GregNoel)>     done 
17:09:08  <[GregNoel](GregNoel)>     2153 
17:09:31  <sgk>  2153:  this is the email jason was referring to 
17:09:36  <jason_at_intel>       so I sent a mail on this to steve.. summarized here 
17:09:54  <sgk>  because long-line tempfiles get created as as a side effect of expanding ${TEMPFILE} in the command line 
17:10:12  <sgk>  the file gets created when we expand the line for display, too 
17:10:32  <sgk>  and since that display expansion doesn't actually get executed, the tempfile deletion never happens 
17:10:51  <Garyo>        hmm, makes sense. 
17:10:18  <jason_at_intel>       not sure on what is the best fix... thinking about MD5 the string to store the tempfile name in the env 
17:11:08  <sgk>  Jason, do you or your intern have cycles to work w/me on fixing this? 
17:11:16  <jason_at_intel>       Yep 
17:11:20  <sgk>  it might be a little involved, because it's not happening at the right time 
17:11:40  <sgk>  but i can provide direction, and if you two have time for the coding+testing, it'll go quicker than if it's on my plate 
17:11:43  <sgk>  okay, cool 
17:11:56  <jason_at_intel>       need to know if the env we pass to the action is unique or not 
17:12:02  <sgk>  2.1 p2 jason then 
17:12:10  <Garyo>        +1 
17:12:08  <[GregNoel](GregNoel)>     done 
17:12:14  <[GregNoel](GregNoel)>     2575 I can post the long comment, but I have commitments that will prevent me from taking much part in the discussion. 
17:12:44  <jason_at_intel>       honestly we have this fixed in Parts without a chdir 
17:13:02  <sgk>  for zip?  or a more general fix? 
17:13:07  <jason_at_intel>       it was so critical, we just made our own zipfile builder 
17:13:10  <Garyo>        I don't think it's too involved, but that's cause I'm pretty sure just passing a prefix or prefix to eliminate to the zipfile stuff is the way to go 
17:13:20  <jason_at_intel>       zipfile, tarfile bz2file 
17:13:31  <jason_at_intel>       it all the same basic code 
17:14:00  <jason_at_intel>       we can review it when i visit 
17:14:28  <sgk>  let's do that 
17:14:34  <Garyo>        I thought at least zipfile can already run w/o chdir 
17:14:32  <jason_at_intel>       I don't know if greg is in the CA area or not 
17:14:41  <jason_at_intel>       I take it he would want to have a say 
17:14:40  <sgk>  greg's in San Diego 
17:14:56  <jason_at_intel>       that pretty far south.. correct? 
17:15:08  <sgk>  yes, prohibitively so 
17:15:27  <jason_at_intel>       :-(.. want to meet the master himself :-) 
17:15:31  <sgk>  but we could at least start looking at it 
17:15:36  <jason_at_intel>       yep 
17:15:41  <Garyo>        How about Greg posting the long comment anyway so we can discuss the interface in the Zip builder, then use your code to implement? 
17:15:51  <sgk>  ++ 
17:15:59  <[GregNoel](GregNoel)>     Garyo, good idea 
17:16:08  <jason_at_intel>       sounds good 
17:16:23  <sgk>  leave it owned as issues@scons and revisit it after discussion? 
17:16:30  <Garyo>        I'm ok w/ that 
17:16:32  <[GregNoel](GregNoel)>     What to do with the issue in the meantime? 
17:16:46  <Garyo>        nothing? 
17:17:02  <[GregNoel](GregNoel)>     ... with a meaning of review next time? 
17:16:59  <jason_at_intel>       is it research? 
17:17:22  <sgk>  yeah, either research or leave it as is, so we revisit it next time 
17:17:23  <Garyo>        I'm ok w/ research jason too -- that way we'll review it. 
17:17:47  <[GregNoel](GregNoel)>     research p1 then? 
17:18:02  <sgk>  done 
17:18:02  <[GregNoel](GregNoel)>     Who should own it? 
17:18:18  <sgk>  [GregNoel](GregNoel) until you post the comment, then re-assign to Jason? 
17:18:19  <Garyo>        Jason imho.  Jason, when's your meeting with sk? 
17:18:38  <jason_at_intel>       aug 18-19 
17:19:10  <jason_at_intel>       I get there aug 17.. . I forget what time. 
17:19:16  <jason_at_intel>       leave early on saturday 
17:19:27  <Garyo>        Anyway we have plenty of time to discuss on the ML 
17:18:53  <Garyo>        ok 
17:18:57  <sgk>  ok 
17:19:01  <[GregNoel](GregNoel)>     done 
17:19:04  <[GregNoel](GregNoel)>     1450 
17:19:22  <jason_at_intel>       ya so this bug 
17:19:54  <Garyo>        1450: Jason, do you have anything that would actually break? 
17:19:56  <jason_at_intel>       My concern is that the fix seems tied to a given version of mslink 
17:20:13  <jason_at_intel>       what about other tools? 
17:20:23  <Garyo>        Yeah, it's a fair point -- newlines in a command line makes me nervous too, even if it works now 
17:20:38  <jason_at_intel>       I might be missing something. 
17:20:46  <jason_at_intel>       but i think more testing is needed 
17:21:02  <Garyo>        Could have two versions TEMPFILE and TEMPFILESPACES or something (yuck) 
17:21:06  <jason_at_intel>       I am under the view that minus link 
17:21:11  <jason_at_intel>       most tools would take a file in a different way 
17:21:09  <sgk>  good lord, a command line that actually blows out the temp file limit?  131K characters? 
17:21:34  <Garyo>        sgk: I think it blows out the line length limit, hence the newlines. 
17:21:54  <Garyo>        and yes, that's a big cmd line! :-/ 
17:22:02  <jason_at_intel>       per line 
17:22:03  <sgk>  the CMD line length limit is already exceeded, that's why it's getting put in the temp file 
17:22:12  <sgk>  i'm trying to figure out if there are two limits at work here 
17:22:43  <sgk>  or at least, our notion of the CMD line length is exceeded 
17:23:01  <sgk>  (bus coming in ~1-2 minutes, i'll have an interrupt) 
17:23:12  <Garyo>        The ticket says it generates LNK1170, a linker error (not cmd.exe) 
17:23:35  <sgk>  good point 
17:23:46  <sgk>  it's the linker that interprets the @tmpfile thing 
17:23:57  <sgk>  gotta run, biab 
17:23:59  *      sgk has quit (Quit: sgk) 
17:24:02  <jason_at_intel>       the fix was to make a new line before that link limit was hit 
17:25:28  <Garyo>        yes -- the fix in the post is to just join all the elements with newlines... 
17:25:57  <Garyo>        I just googled it and even vs2010 has this limit (128k chars on a line) and the suggested workaround is the same, use newlines 
17:26:17  <jason_at_intel>       I believe the icl, cl and link tools handle input files in this format 
17:27:05  *      sgk (~[sgk@67.218.107.184](mailto:sgk@67.218.107.184)) has joined #SCONS 
17:27:16  <sgk>  hello again 
17:27:18  <[GregNoel](GregNoel)>     So what to do with the issue?  We've pretty much reached the discussion limit. 
17:27:19  <Garyo>        right.  Your point is that TEMPFILE could be used for other tools which might barf on newlines, right? 
17:27:31  <jason_at_intel>       yep 
17:27:47  <Garyo>        I think either (a) an arg to TEMPFILE for what spacer to use, or (b) two versions of TEMPFILE 
17:28:05  <jason_at_intel>       ... I think it would be easy to tweak tempfile to workaround this however.. I think 
17:28:20  <sgk>  yeah, we can make TEMPFILE configurable in some way 
17:28:31  <Garyo>        that'd be my 1st choice. 
17:28:58  <jason_at_intel>       if we can pass in a separator value to be used to the $Tempfile call.. i do stuff like this in Parts with the mappers objects 
17:29:07  <[GregNoel](GregNoel)>     So what to do with the issue?  We've pretty much reached the discussion limit. 
17:29:23  <sgk>  jason 2.1 p3 ? 
17:29:28  <jason_at_intel>       Since I seem to be fixing it.. I can take a stab at it 
17:29:40  <Garyo>        Jason, if you'll investigate it that'd be awesome. 
17:29:46  <[GregNoel](GregNoel)>     done 
17:29:52  <[GregNoel](GregNoel)>     2281 I'll go with research sk; what priority? 
17:30:11  <sgk>  i think it's a corner case, so I'd suggest p4 
17:30:19  <Garyo>        fine w/ me 
17:30:24  <[GregNoel](GregNoel)>     done 
17:30:34  <[GregNoel](GregNoel)>     2285 
17:30:53  <sgk>  2.1 p4 sk 
17:31:09  <[GregNoel](GregNoel)>     done 
17:31:11  <[GregNoel](GregNoel)>     2380 
17:31:11  <Garyo>        I think it has to be -- only you understand that stuff 
17:31:19  <sgk>  yeah 
17:31:21  <sgk>  :-( 
17:31:44  <jason_at_intel>       I woudl want to talk to you about this as well when i visit 
17:31:54  <Garyo>        2380?  Is it controversial? 
17:31:55  <sgk>  2380:  2.1 p4 ...  who? 
17:32:05  <jason_at_intel>       I want Scons to handle symlink and hardlinks on windows 
17:32:19  <jason_at_intel>       I Have it working.. but it really needs fixes in SCons 
17:33:04  <jason_at_intel>       then there is permission issues on windows.. so link might have to copy 
17:33:20  <Garyo>        I could do it but not for 2.1.  If it's me, it'd be 2.2 p3 garyo 
17:33:58  <Garyo>        (2380, not symlinks on windows of course) 
17:34:03  <sgk>  since it's low priority, 2.x p3 and punt on assigning someone for now? 
17:34:46  <[GregNoel](GregNoel)>     Hearing no objection, done 
17:34:50  <Garyo>        ok 
17:34:49  <[GregNoel](GregNoel)>     1745 
17:35:09  <Garyo>        see my comment 
17:35:16  <jason_at_intel>       ya.. but the issue is related to the File.<api> that needs to replace all os.<fileapi> calls 
17:35:38  <jason_at_intel>       :-) 
17:35:38  <sgk>  we've been loading up jason 
17:35:39  <Garyo>        jason, I think 1745 can be fixed w/o any of that. 
17:35:54  <sgk>  i see bdbaddog's signed in, is bill here? 
17:35:59  <bdbaddog>     yes 
17:36:48  <sgk>  bill, any of these look up your alley? 
17:36:20  <jason_at_intel>       why i think making all files precious is better than deleting them by default 
17:37:08  <Garyo>        ok, but the minimal change for 1745 is just to make the .ilk file a side effect. 
17:37:25  <sgk>  ah 
17:37:25  <jason_at_intel>       so is there anyway we can modify the object builder on windows? 
17:37:29  <Garyo>        Making incremental links work should maybe be a separate ticket. 
17:37:29  <bdbaddog>     so mslink emitter work then right? 
17:37:31  <jason_at_intel>       I am not sure where that is 
17:37:53  <Garyo>        bdbaddog: seems like it to me 
17:37:54  <sgk>  agree w/garyo re: a separate ticket for incremental links 
17:38:11  <jason_at_intel>       so this bug directly, is just a addition to .ilk files 
17:38:16  <jason_at_intel>       as a sideeffect 
17:38:24  <jason_at_intel>       given that the flags support it 
17:38:31  <bdbaddog>     are the .ilk's always generated? 
17:38:45  <bdbaddog>     or do some ms flags enable/disable them? 
17:38:46  <jason_at_intel>       there is some flag to force no incremental build 
17:38:47  <Garyo>        unless /noincremental or something like that 
17:39:08  <Garyo>        but I think it's ok to declare a side effect that doesn't get generated 
17:39:12  <Garyo>        (right?) 
17:39:28  <sgk>  i think so 
17:39:38  <[GregNoel](GregNoel)>     I think so, too 
17:39:18  <bdbaddog>     o.k. I can take it then. 
17:39:27  <Garyo>        thanks! 
17:39:38  <bdbaddog>     if the scope is .ilk's get deleted with --clean afterwards. 
17:39:54  <Garyo>        agreed, minimal scope 
17:39:59  <sgk>  yeah, if it turns into something bigger than that, we should re-review it 
17:40:04  <[GregNoel](GregNoel)>     milestone and priority? 
17:40:19  <Garyo>        2.1 p4, imho 
17:41:35  <sgk>  sounds good, bdbaddog++ 
17:40:23  <sgk>  the only pitfall i can think of is if non-existent side-effect files trigger unnecessary rebuilds 
17:40:29  <sgk>  i don't think they do, but i don't remember 
17:40:47  <bdbaddog>     sgk: 99% sure you're right 
17:40:50  <Garyo>        sgk: I'm pretty sure not. 
17:41:06  <[GregNoel](GregNoel)>     sgk, I'm pretty sure they don't; that's why Russel uses them in the LaTeX builder. 
17:40:45  <sgk>  we should set a target date for 2.1 
17:40:23  <bdbaddog>     when are we thinking 2.1 will be? 
17:40:50  <sgk>  discuss after the issues? 
17:41:39  <[GregNoel](GregNoel)>     milestone and priority? 
17:41:41  <Garyo>        roadmap says 2.1 rc sept, 2.1 final oct. 
17:42:04  <sgk>  1745:  2.1 p4 bdbaddog 
17:42:13  <[GregNoel](GregNoel)>     done 
17:42:18  <jason_at_intel>       ahh the option is /INCREMENTAL 
17:42:51  <sgk>  why'd they pick an obscure option like that to control incremental linking?  :-) 
17:42:16  <[GregNoel](GregNoel)>     2355 
17:43:12  <Garyo>        2355 clearly needs research. 
17:43:34  <jason_at_intel>       I agree 
17:44:49  <jason_at_intel>       worse case the builder can add a cd <dir> && before the command is the subprocess thing does not work 
17:44:03  <Garyo>        Greg, would you like to look into the subprocess thing? 
17:45:00  <[GregNoel](GregNoel)>     Er, no.  I already know chdir= doesn't affect the main process on a Real Operating System; the question is about lesser operating systems. 
17:45:24  <bdbaddog>     You mean like MacOS right...;) 
17:45:57  <jason_at_intel>       should be simple to test 
17:46:24  <Garyo>        Simple to test, a bit scary to implement I think 
17:46:27  <sgk>  heh 
17:45:21  <Garyo>        In any case it doesn't seem practical to get into 2.1.  How about aiming for 2.2? 
17:46:58  <[GregNoel](GregNoel)>     Well, we've always had converting to subprocess() as a goal, but not in 2.1 I don't believe. 
17:47:32  <bdbaddog>     GN: I agree.. 2.2 
17:47:33  <Garyo>        So maybe this will just fall out of that conversion? 
17:47:38  <Garyo>        That'd be great. 
17:47:40  <jason_at_intel>       it seem doing subprocess in SCons first then chdir seem to be the best order 
17:47:50  <Garyo>        Agreed. 
17:47:51  <bdbaddog>     JAI: +1 
17:48:19  <sgk>  [GregNoel](GregNoel):  looks like it's ok on windows, the cwd= argument is passed to [CreateProcess](CreateProcess)() 
17:48:49  <sgk>  yeah, subprocess first 
17:48:55  <bdbaddog>     +1 
17:48:59  <bdbaddog>     should we file a bug for that? 
17:49:11  <sgk>  if there isn't one already open, yes 
17:50:09  <bdbaddog>     1955 might be part of that.. 
17:50:24  <Garyo>        was just looking at that one 
17:50:53  <[GregNoel](GregNoel)>     What to do with this issue?  We're running short on time. 
17:51:10  <bdbaddog>     2.2 
17:51:14  <Garyo>        2.2 (but after subprocess), p2, whoever does subprocess. 
17:51:14  <sgk>  2.2 sounds right 
17:51:19  <jason_at_intel>       Say it depend on SCons Subprocess work 
17:51:43  <sgk>  1955 is dup with others that deal with long lines 
17:51:53  <sgk>  so I'll open an issue for the subprocess work 
17:52:04  <sgk>  and then we make 2355 depends on that one 
17:52:14  <Garyo>        sgk: +1 
17:52:35  <[GregNoel](GregNoel)>     sgk, yes, but what for this issue? 2.2 p2?  Who owns it? 
17:52:01  <jason_at_intel>       I might be able to help with that as well 
17:52:09  <jason_at_intel>       as Parts does this in SCons... 
17:52:26  <sgk>  jason_at_intel:  cool, thanks 
17:52:35  <jason_at_intel>       not sure what is scons defines the default "SPAWN" function however.. so i have not made a patch to SCons 
17:53:05  <Garyo>        Greg: I recommend assigning to sgk for now, he can reassign later if desired. 
17:53:11  <bdbaddog>     +1 
17:53:12  <bdbaddog>     :) 
17:53:13  <sgk>  sounds good 
17:53:18  <jason_at_intel>       +1 
17:53:16  <[GregNoel](GregNoel)>     done 
17:53:18  <[GregNoel](GregNoel)>     That covers the issues@scons issues; on to the new issues. 
17:53:18  <[GregNoel](GregNoel)>     2649 I'll go with research sk; what priority? 
17:53:40  <Garyo>        p3 
17:54:06  <[GregNoel](GregNoel)>     sgk?  What say you? 
17:54:33  <sgk>  yes 
17:54:38  <[GregNoel](GregNoel)>     done 
17:54:41  <[GregNoel](GregNoel)>     2650 consensus review next time 
17:54:41  <[GregNoel](GregNoel)>     2657 
17:55:14  <Garyo>        2.1 p2 sk 
17:55:19  <jason_at_intel>       Glad i have not seen this on our 64-bit boxes yet 
17:55:26  <sgk>  consensus 2.1 p2 sk done 
17:55:29  <[GregNoel](GregNoel)>     done 
17:55:31  <[GregNoel](GregNoel)>     2660 consensus research sk; what priority? 
17:55:40  <sgk>  p3 
17:56:08  <[GregNoel](GregNoel)>     done 
17:56:14  <[GregNoel](GregNoel)>     2661 consensus 2.1 p2 Bill 
17:56:14  <[GregNoel](GregNoel)>     2662 OK, I'll take it as 2.2 p4 
17:56:14  <[GregNoel](GregNoel)>     2663 consensus 2.1 p3 Bill 
17:56:14  <[GregNoel](GregNoel)>     That appears to be it for the day...  Anything else? 
17:56:28  <Garyo>        nice work all, just under an hour 
17:56:32  <sgk>  oh, heh:  my comment about 2661 was "try to keep SCons reasonably current with VC tools" 
17:56:34  <bdbaddog>     1.3.1.. push out from last checkpoint? 
17:57:04  <sgk>  yes 
17:56:56  <Garyo>        bdbaddog: absolutely.  No complaints whatsoever that I've heard. 
17:57:49  <bdbaddog>     what about last 2.0.1 checkpoint? release as 2.0.1? rebranch to remove extra changes? other? 
17:58:49  <Garyo>        I think we should try not to be pedantic -- push out as 2.0.1 as is, let's get going on 2.1 work. 
17:59:15  <Garyo>        (?) 
17:59:21  <bdbaddog>     +1 from me. 
18:00:06  <sgk>  +1 
18:00:31  <jason_at_intel>       +1 for me... I think the patches added here make the first drop we can use at work without breaking anything 
18:01:49  <jason_at_intel>       ( since 1.2) 
18:01:36  <bdbaddog>     K. then I'll try and roll out 1.3.1 and 2.0.1 this weekend. 
18:01:46  <Garyo>        yay bdbaddog! 
18:01:29  <sgk>  so 2.1 release candidate in september--shall we pick a week to target? 
18:01:56  <bdbaddog>     I'm on vaca the whole first week thereof. 
18:02:09  <bdbaddog>     so later in ssept would be better. 
18:02:42  <sgk>  hmm, looking at the roadmap, i realize my real question is, when do we want to start releasing pre-2.1 checkpoints? 
18:03:00  <sgk>  the roadmap suggests one in july and one in august 
18:03:14  <sgk>  i'm trying to give myself a tangible near-term deadline to get going on some of these things 
18:03:51  <Garyo>        Don't think we have enough in yet for one now.  Maybe end of July? 
18:03:17  <bdbaddog>     has trunk diverged from 2.0.1 much? 
18:03:57  <sgk>  not much yet, but I'm about to start making some big doc changes 
18:04:01  <Garyo>        I'll try to get a few more things done soon. 
18:04:12  <Garyo>        This weekend e.g. 
18:04:26  <sgk>  okay, ditto 
18:04:52  <bdbaddog>     so checkpoint 7/31? 
18:05:01  <Garyo>        Let's aim for that. 
18:05:05  <sgk>  sounds like a good stake in the ground 
18:05:07  <bdbaddog>     k. 
18:05:30  <sgk>  any other issues to cover? 
18:06:09  <sgk>  going once... 
18:06:10  <jason_at_intel>       not from me... I will send some questions tomorrow to get tempfile working 
18:06:11  <Garyo>        none here 
18:06:11  <bdbaddog>     nope. 
18:06:13  <sgk>  going twice... 
18:06:18  <sgk>  okay, sold 
18:06:24  <sgk>  thanks for the good work, everyone 
18:06:39  <[GregNoel](GregNoel)>     G'night all... 
18:06:40  <Garyo>        bye 4 now 
18:06:43  <bdbaddog>     gnight 
18:06:44  <sgk>  bye 
18:06:46  *      sgk (~[sgk@67.218.107.184](mailto:sgk@67.218.107.184)) has left #SCONS 
18:06:47  <jason_at_intel>       night! 
18:06:58  *      You have been marked as being away 
18:07:22  *      jason_at_intel has quit (Quit: [ChatZilla](ChatZilla) 0.9.86 [Firefox 3.6.6/20100625231939]) 
21:23:49  *      Garyo has quit (Quit: [ChatZilla](ChatZilla) 0.9.86 [Firefox 3.6.7/20100713130626]) 
23:42:18  *      bdbaddog has quit (Quit: Leaving.) 

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.