Skip to content
William Deegan edited this page Jan 14, 2016 · 2 revisions
16:53:37  *      bdbaddog (~[bdeegan@adsl-71-131-20-38.dsl.sntc01.pacbell.net](mailto:bdeegan@adsl-71-131-20-38.dsl.sntc01.pacbell.net)) has joined #scons 
16:59:35  *      [GregNoel](GregNoel) is no longer marked as being away 
16:59:43  *      Jason_at_Intel (~[chatzilla@12.18.240.224](mailto:chatzilla@12.18.240.224)) has joined #scons 
17:03:01  *      sgk (~sgk@nat/google/x-qeheyykyhlqublpj) has joined #scons 
17:03:10  <[GregNoel](GregNoel)>     Hey, Steven... 
17:03:16  <sgk>  hey 
17:03:20  <Jason_at_Intel>       hello steve 
17:03:25  <bdbaddog>     Greetings! 
17:04:08  <[GregNoel](GregNoel)>     I see bdbaddog, Jason_at_Intel, techtonik, and loonycyborg here; are you all here for the bug party? 
17:04:21  <Jason_at_Intel>       yep 
17:04:27  <bdbaddog>     Unless theres some other party going on.. ;) 
17:05:05  *      loonycyborg loves celebrating bugs :P 
17:05:55  *      sgk still hasn't recovered from the weekend 
17:06:15  <[GregNoel](GregNoel)>     Gary's on a tiny island in the Carribean (which I can't spell), so I doubt he's gonna show.  Shall we start? 
17:06:22  <sgk>  let's do it 
17:06:40  <[GregNoel](GregNoel)>     1910, sgk wanted to talk about it 
17:06:59  <sgk>  yeah, i updated with a patch and explanation of the (minor) dilemma 
17:07:13  <sgk>  there's this functionality i had totally forgotten about 
17:07:26  <sgk>  where if you set a BUILDERS entry to a function (or other callable) 
17:07:35  <sgk>  it's okay as long as calling that function *returns* a builder 
17:07:54  <sgk>  this makes it kind of like what we currently advise people do with [AddMethod](AddMethod)() 
17:08:17  <sgk>  except that [AddMethod](AddMethod)() is generic, so to make something added via [AddMethod](AddMethod)() look like a real Builder 
17:08:25  <sgk>  you have to do your own argument interpretation, etc. 
17:09:05  <sgk>  adding a callable wrapper to a BUILDERS entry makes it look more like a real Builder automatically 
17:09:45  <[GregNoel](GregNoel)>     What do you want to do with it? 
17:09:54  <sgk>  i wanted to discuss because supporting this features means the 1910 OP doesn't get his problem solved 
17:10:10  <sgk>  because he was setting BUILDERS to a function that didn't return a Builder 
17:10:14  <sgk>  which is a condition we can't quite catch 
17:10:44  <sgk>  i think the best we can do is document that you can add callables to BUILDERS 
17:11:21  <sgk>  and add the patch so if you add a non-Builder, non-callable to BUILDERS there's at least a coherent error message 
17:11:26  <sgk>  sound good? 
17:11:37  <Jason_at_Intel>       this is 1910? 
17:11:41  <sgk>  yes 
17:11:42  <[GregNoel](GregNoel)>     That sounds good to me 
17:11:45  <Jason_at_Intel>       I thought this was about scanners? 
17:11:58  <sgk>  erk... 
17:12:00  <sgk>  you're right 
17:12:04  <sgk>  next one in the spreadsheet, 780 
17:12:05  <sgk>  sorry 
17:12:16  <Jason_at_Intel>       ahh 
17:12:21  <Jason_at_Intel>       so 780 
17:12:31  <sgk>  1910 i don't think needs discussion 
17:12:51  <sgk>  unless someone's eager to pick up my partial fix and track down the last failing test case 
17:13:21  <Jason_at_Intel>       mean is you add a builder directly to the env['BUILDERS'] that is a function .. and not a builder we have an issue 
17:13:01  <bdbaddog>     can you detect that the builder didn't return a builder? 
17:13:31  <bdbaddog>     I mean that the callable didn't return a builder on it's first call? 
17:13:58  <sgk>  bdbaddog:  you're right, we could do that; i didn't think of that 
17:14:25  <sgk>  I was too focused on making it happen at SConscript read time 
17:14:32  <bdbaddog>     every now and then a synapse fires.. 
17:14:38  <bdbaddog>     :) 
17:14:46  <sgk>  ...or misfires...  :-) 
17:15:25  <bdbaddog>     either way.. 
17:15:38  <[GregNoel](GregNoel)>     I think that sounds reasonable.  Do you want to keep it and update the info, or should I try to make sense of it? 
17:16:02  <sgk>  okay, unless anyone objects, i'll take back the issue and try to finish that part of it 
17:16:08  <[GregNoel](GregNoel)>     done 
17:16:15  <Jason_at_Intel>       sounds good 
17:16:26  <bdbaddog>     +1 
17:16:30  <sgk>  onward... 
17:16:30  <[GregNoel](GregNoel)>     2549? 
17:16:39  <sgk>  looks like consensus, wait for OP 
17:16:53  <[GregNoel](GregNoel)>     OK, bypass until next time 
17:16:51  <Jason_at_Intel>       so what about 1910? 
17:17:22  <sgk>  1910:  i uploaded a fix that's about 95% complete, but induces one regression 
17:17:30  <sgk>  it's reassigned to garyo 2.x p4 
17:17:43  <sgk>  he or anyone else can pick up and try to finish it 
17:17:38  <[GregNoel](GregNoel)>     2552, consensus 
17:18:05  <[GregNoel](GregNoel)>     2558, ditto 
17:18:34  <sgk>  2558:  i can go w/P3 so the OP gets some activity hopefully sooner than a P4 
17:18:56  <[GregNoel](GregNoel)>     I'm good with that 
17:19:00  <bdbaddog>     +1 
17:19:03  <[GregNoel](GregNoel)>     done 
17:19:17  <sgk>  2562:  consensus 
17:19:20  <[GregNoel](GregNoel)>     2562, needs an owner 
17:19:34  <bdbaddog>     I'll take it 
17:19:43  <[GregNoel](GregNoel)>     done 
17:19:55  <[GregNoel](GregNoel)>     2565 
17:20:34  <bdbaddog>     sounds like a doc only to me. 
17:20:47  <sgk>  2565 feels like either a research thing, or else outright invalid 
17:21:16  <sgk>  research with an eye towards clarifying / expanding the doc 
17:21:52  <[GregNoel](GregNoel)>     After reading sgk's spreadsheet comments, I think fixing the doc so that fooCOMSTR and SHfooCOMSTR refer to each other is the right solution. 
17:22:30  <[GregNoel](GregNoel)>     It would have prevented the issue in the ML and then here. 
17:20:40  <[GregNoel](GregNoel)>     so 2565 is a small bit of editing, but needs someone who can take the time. 
17:23:01  <Jason_at_Intel>       +1 
17:22:38  <bdbaddog>     o.k. do we need to put sometihng in 1.3 docs indicating this will be changing in 2.0 ? 
17:23:12  <bdbaddog>     so env['SHCXXCOMSTR']='$CXXCOMSTR -shared_flag' ? 
17:23:22  <[GregNoel](GregNoel)>     It's not changing; that's the point. 
17:23:49  <bdbaddog>     oh.. o.k. I c read ur message wrong. 
17:23:52  <Jason_at_Intel>       I not sure.. but this might be a good idea to also see about adding a make_unique call when subst on some value 
17:24:13  <[GregNoel](GregNoel)>     Not in this issue, KISS 
17:24:21  <bdbaddog>     +1 doc only 
17:24:30  <[GregNoel](GregNoel)>     agree 
17:24:40  <Jason_at_Intel>       I know we have been getting long CLI lines ... when fixing this up this might be worth thinking about 
17:25:13  <[GregNoel](GregNoel)>     Not in this issue, open another issue if you want to think about it 
17:25:24  <Jason_at_Intel>       sure 
17:26:03  <[GregNoel](GregNoel)>     So, consensus for doc, but who and when? 
17:27:15  <[GregNoel](GregNoel)>     It's a small bit of editing.  I'd take it, but my time is going to be so chopped up over the next couple of months, I'd hate to promise anything. 
17:28:34  <sgk>  2565:  i'll take it 
17:28:38  <sgk>  2.x p3? 
17:28:53  <[GregNoel](GregNoel)>     Sooner?  2.1 p3? 
17:29:00  <sgk>  okay, 2.1 p3 
17:29:08  <[GregNoel](GregNoel)>     done 
17:29:19  <[GregNoel](GregNoel)>     2566 
17:29:28  <sgk>  2566:  consensus garyo more info from OP 
17:29:37  <[GregNoel](GregNoel)>     yep 
17:29:49  <[GregNoel](GregNoel)>     2568 
17:30:31  <[GregNoel](GregNoel)>     Bill and Gary say 2.1 (in the wrong column)... 
17:30:34  <sgk>  it's pretty easy, i was thinking a regex to match an arbitrary number of / or \ 
17:30:51  <[GregNoel](GregNoel)>     Or :? 
17:31:15  <[GregNoel](GregNoel)>     (separator for MacOS classic) 
17:31:21  <sgk>  heh 
17:31:44  <sgk>  just what we need, drop support for Python 1.5.2 while we add support for Mac OS 9 
17:31:55  <[GregNoel](GregNoel)>     {;-} 
17:32:11  <[GregNoel](GregNoel)>     I was just making the point that there could be other separators 
17:32:28  <Jason_at_Intel>       vms 
17:31:25  <bdbaddog>     os.pathsep ? 
17:31:31  <bdbaddog>     or os.dirsep? 
17:31:42  <bdbaddog>     I think python will give you the native character. 
17:32:10  <sgk>  right now it matches os.pathsep and explicit '/' 
17:32:34  <sgk>  sorry, os.sep, not os.pathsep 
17:33:21  <sgk>  give it to me, i'll knock it out quickly just to get it off the list 
17:33:31  <[GregNoel](GregNoel)>     OK, when? 
17:33:33  <sgk>  2.1 p4? 
17:33:38  <bdbaddog>     +1 
17:33:41  <[GregNoel](GregNoel)>     done 
17:34:11  <[GregNoel](GregNoel)>     2569, agree with Steven's comment 
17:35:04  <[GregNoel](GregNoel)>     If I knew what it was supposed to do, I could hack out a RE in a few minutes 
17:35:45  <[GregNoel](GregNoel)>     If someone writes a spec, I'll code it. 
17:34:38  <sgk>  2569:  Jason_at_intel, do .rc files behave like this issue implies? 
17:34:55  <sgk>  he's suggesting change the .rc scanner so it finds included files 
17:35:06  <Jason_at_Intel>       Have not used them for a while as they are replaced with a new format 
17:36:16  <sgk>  his RE is fine for matching any line of form 
17:36:21  <sgk>  KEYWORD KEYWORD "filename" 
17:36:29  <sgk>  the problem isn't lack of RE expertise 
17:37:01  <sgk>  it's whether or not .rc files can have lines that match that expansive RE and which *aren't* actually included files 
17:37:04  <[GregNoel](GregNoel)>     'I want "filename" to be part of the resource' 
17:37:37  <bdbaddog>     push back to the filer to point us at a URL where the file's speced? 
17:38:11  <[GregNoel](GregNoel)>     RE evaluation is in C; the algorithm looks at each character at most once, so it doesn't matter how complicated it is. 
17:38:36  <[GregNoel](GregNoel)>     Cost is O(strlen) 
17:39:10  <sgk>  [GregNoel](GregNoel):  ?  what you say is all true, but i don't see the relevance 
17:39:21  <bdbaddog>     well we ahve a bit of time to decide on this, lets defer it ? 
17:39:44  <[GregNoel](GregNoel)>     bdbaddog, I won't disagree with that. 
17:40:20  <bdbaddog>     can we punt and goto 2570? 
17:40:38  <[GregNoel](GregNoel)>     2570 is consensus, and it's the last one 
17:40:28  <Jason_at_Intel>       the issue is about a new pattern that look for "filename" or <filename> 
17:40:52  <sgk>  that old pattern matched both < and " 
17:40:54  <bdbaddog>     I"m not sure it's really a bug yet. 
17:40:55  <Jason_at_Intel>       I agree that i worry that "" has other meanings.. such as being a string constant 
17:41:05  <sgk>  his issue is that we have a hard-coded list of keywords in the old RE: 
17:41:17  <sgk>  ICON|BITMAP|CURSOR|HTML|FONT|MESSAGETABLE|TYPELIB|REGISTRY|D3DFX 
17:41:29  <sgk>  and he wants to be able to match other custom keywords like XAML 
17:41:33  <Jason_at_Intel>       and new ones like xaml are not supported 
17:41:45  <sgk>  so his RE no longer looks for explicit keyword like the old one 
17:42:17  <sgk>  but matches any keyword in the second argument 
17:43:10  <sgk>  research, me 
17:43:21  <sgk>  i can send it to a day-job .rc expert 
17:43:34  <[GregNoel](GregNoel)>     That makes sense.  +1 
17:43:49  <Jason_at_Intel>       +1 
17:44:10  <[GregNoel](GregNoel)>     done 
17:44:23  <[GregNoel](GregNoel)>     That seems to be it for the issues.  1.3? 
17:44:42  <sgk>  bdbaddog, how's it going?  anything you could use help on? 
17:44:47  <bdbaddog>     I think it's just 2570, checkpoint and then go? 
17:45:01  <bdbaddog>     I'm trying to figure out if 2570 is really a bug. 
17:45:56  <sgk>  k 
17:45:56  <bdbaddog>     if you create an environment with no tool= spec, then later (on windows) say Tool('msvc')(env) 
17:46:09  <bdbaddog>     will that reset the tool? I don't think so 
17:47:04  <bdbaddog>     I think he was just getting lucky before because he was asking for the newest version of VC on the machine, when he installed one newer than the one he was asking for his logic broke. 
17:47:17  <bdbaddog>     Just taking a little time to get an appropriate VM setup. 
17:48:34  <bdbaddog>     hoping to resolve it in the next few days and get another checkpoint out. 
17:49:10  <[GregNoel](GregNoel)>     (silence) 
17:49:28  <sgk>  sounds good to me 
17:49:55  <sgk>  anyone think we should push the checkpoint w/out 2570? 
17:50:18  <[GregNoel](GregNoel)>     I'd prefer not. 
17:50:27  <sgk>  agreed, just double-checking 
17:50:36  <Jason_at_Intel>       from what i know the layout shoudl not change with the finial release 
17:50:57  <bdbaddog>     k. 
17:51:13  <Jason_at_Intel>       so getting working now will help when 2010 is finally released 
17:51:37  <sgk>  cool 
17:51:45  <sgk>  any other 1.3-related topics or questions? 
17:51:57  <[GregNoel](GregNoel)>     Is that all?  If so, while Steven and Bill are here, I have a couple of off-topic things. 
17:53:16  <Jason_at_Intel>       well I am going to take off.. have bugs to fix 
17:53:28  <Jason_at_Intel>       till next time! 
17:53:31  <[GregNoel](GregNoel)>     cul 
17:53:39  <sgk>  later, thnx 
17:53:50  *      Jason_at_Intel has quit (Quit: [ChatZilla](ChatZilla) 0.9.86 [Firefox 3.5.3/20090824101458]) 
18:05:38  <bdbaddog>     k. I"m off to the gym. starting to train for a triathlon.. :) 
18:05:53  <sgk>  good luck 
18:06:27  <[GregNoel](GregNoel)>     agreed 
18:08:58  <sgk>  okay, later 
18:08:58  <sgk>  thnx 
18:09:00  <[GregNoel](GregNoel)>     cul, bye 
18:09:07  *      sgk (~[sgk@67.218.106.179](mailto:sgk@67.218.106.179)) has left #scons 
18:09:13  *      [GregNoel](GregNoel) has been marked as being away 
18:15:13  *      loonycyborg has quit (Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz) 

Clone this wiki locally