1 19:21:47 <sgk_> 2124:
2 19:22:16 <sgk_> brandon, it's the open filehandles thing?
3 19:22:21 <Azverkan> yeah
4 19:22:23 <GregNoel> I think he's getting the errors because the shims aren't being installed
5 19:22:33 <Azverkan> I reproduced the bug localluy
6 19:22:43 <GregNoel> With the shims?
7 19:22:57 <Azverkan> I haven't figured out whether I can reproduce the problem with Microsoft's CL.EXE yet
8 19:23:03 <Azverkan> err wihtout
9 19:23:10 <Azverkan> it might be something specific to what they are doing
10 19:23:17 <sgk_> if it's without then it's a known issue
11 19:23:26 <sgk_> and we need to fix the other bug where the message isn't getting printed
12 19:23:49 <GregNoel> Yes, the fact that he found the bug suggests that he should have been getting the message.
13 19:23:51 <sgk_> i also think we probably need to make those shims Yet Another configurable item
14 19:24:15 <GregNoel> Why would you want to turn them off?
15 19:24:20 <sgk_> Carsten's message on the ML about compiler output getting lost when redirected is because of the shims, I think
16 19:24:28 <Azverkan> I think it might only applicable to applications that CreateFile with non default filesharing params, but I need to narrow it down more yet
17 19:25:21 <sgk_> but that would need to be confirmed
18 19:25:30 <Azverkan> whats the "shim"?
19 19:25:33 <sgk_> that aside, where does it leave us for 2124?
20 19:25:45 <GregNoel> Hmmm... Sounds to me like Brandon should be working on it
21 19:25:58 <Azverkan> I think its a real bug that probably won't get fixed in the 1.0.x timeframe
22 19:25:59 <sgk_> we replace the Python open() call (__builtin__.open()) with our own wrapper that calls the real underlying open()
23 19:26:00 <GregNoel> shim ==> code in Platform/win32 that replaces open() and file()
24 19:26:19 <sgk_> and then calls the win32 api to supress the filehandle inheritance
25 19:27:19 <Azverkan> can verify while we move on to other bugs
26 19:27:29 <sgk_> okay, cool
27 19:27:29 <GregNoel> 2124: Brandon, research?
28 19:27:34 <sgk_> done
29 19:27:51 <GregNoel> We'll see if he comes up with anything before we go
30 19:27:50 <sgk_> 2155:
31 19:28:10 <sgk_> okay
32 19:28:18 <GregNoel> 2155: consensus invalid
33 19:28:23 <sgk_> 2155: sounds like we agree to deprecate it
34 19:29:07 <sgk_> guess that would mean holding this open for now ut changing it to track the eventual deprecation?
35 19:29:12 <GregNoel> OK, I'll untangle it; probably put a note in 2126
36 19:29:29 <sgk_> cool, thanks
37 19:29:26 <Azverkan> is there a naming convention for internal vs external functions?
38 19:29:33 <sgk_> not really
39 19:29:53 <sgk_> the closest we have is that, in general, public functions have CamelCase spelling
40 19:30:02 <GregNoel> External usually have caps; internal not, but it's not completely reliable
41 19:30:07 <sgk_> but there are plenty of things like subst() that have gained currency
42 19:30:34 * sgk_ wishes he had GregNoel's gift for brevity
43 19:30:53 <sgk_> i always take a lot of extra words to say things...
44 19:30:56 * GregNoel can't type fast, so he learned to be brief
45 19:31:28 <sgk_> okay, 2155: GregNoel to handle
46 19:31:46 <GregNoel> done
47 19:31:57 <GregNoel> 2157?
48 19:32:20 <sgk_> 2157: fixing ^C in configure context in general is WONTFIX
49 19:32:42 <sgk_> but making sure we don't record an interrupt as a cached failure is... 1.x p3?
50 19:33:07 <GregNoel> it's probably the same thing; a partial store of something
51 19:33:49 <GregNoel> I'll go with looking at it again as 1.x p3
52 19:33:58 <sgk_> done
53 19:34:16 <GregNoel> 2158?
54 19:34:19 <sgk_> 2158: consensus 1.0.1 p4 anybody
55 19:34:25 <GregNoel> done
56 19:34:39 <GregNoel> so who?
57 19:34:41 <sgk_> OMG we got through the current issues
58 19:34:54 <GregNoel> only four!
59 19:35:03 <sgk_> and in only half an hour!
60 19:35:14 <GregNoel> true.
61 19:35:20 * sgk_ is feeling full of piss and vinegar
62 19:35:29 <sgk_> on to the backlog!
63 19:35:36 <GregNoel> Should we assign someone when we re-triage?
64 19:35:44 <sgk_> for 2158?
65 19:35:47 <GregNoel> yes
66 19:36:05 <sgk_> who?
67 19:36:32 <GregNoel> Anyone: you, me, Gary, Brandon. It's one line of code!
68 19:36:42 <sgk_> me
69 19:36:45 <GregNoel> done
70 19:37:58 <sgk_> well, let's at least kill those last 2006H2 bugs
71 19:38:24 <GregNoel> yes, just getting set up. My network is slow today
72 19:38:32 <GregNoel> 1490
73 19:39:04 <Azverkan> (output from scons -j50 is funny btw, currently inserts other command lines between the \r and \n on windows so you get all sorts of weird line termination and interleaved output)
74 19:39:40 <sgk_> Brandon: like with -j3 you can get ccclll...eeexxxeee ///fffooo
75 19:39:42 <sgk_> that sort of thing?
76 19:40:08 <Azverkan> all sorts of extended ascii characters and whatnot
77 19:40:28 <Azverkan> depends what code page you have setup
78 19:40:29 <sgk_> yeah, we need something that slurps up that stuff and controls the output
79 19:40:45 <sgk_> 1490: boy, do i wish we had an installer guru
80 19:40:53 <GregNoel> that's the colorizer issue
81 19:41:02 <GregNoel> 1490, yes
82 19:41:09 <sgk_> agreed re: colorizer
83 19:41:26 <GregNoel> As I said in the spreadsheet, I have no clue.
84 19:41:42 <GregNoel> you two have to work it out
85 19:42:03 <sgk_> let's say 1.x p3 (my favorite)
86 19:42:15 <sgk_> since we have no one immediate to research it
87 19:42:33 <GregNoel> Brandon? If you agree, I'll go along
88 19:42:38 <sgk_> i can try to recruit someone who knows about installation
89 19:43:03 <sgk_> i have a couple of people in mind who might be suitable
90 19:43:16 <GregNoel> And an AIX guru, and a Solaris guru, and ...
91 19:43:33 <sgk_> agreed
92 19:44:04 <Azverkan> 1490 we are using the stock installer
93 19:44:21 <Azverkan> I'd say wontfix with use a different install method?
94 19:44:38 <sgk_> right, and it's getting clearer that stock distutils installer isn't up what we need
95 19:45:10 <GregNoel> I like wontfix; it closes an issue
96 19:45:12 <sgk_> how about 1.x p3 me
97 19:45:33 <GregNoel> OK, although you've got too much work
98 19:45:34 <sgk_> eh, i don't like losing input for when someone takes a look at it
99 19:45:44 <sgk_> yeah, but i'd take this with the intent of passing it off
100 19:45:48 <sgk_> once i find someone
101 19:45:51 <GregNoel> works for me
102 19:45:59 <sgk_> done
103 19:46:03 <GregNoel> 1.x p3, then
104 19:46:39 <sgk_> 1500: sounds like it might be a generic path interpretation issue
105 19:46:44 <sgk_> research, who?
106 19:46:50 <GregNoel> I think 1500 is a mingw v. native issue
107 19:47:34 <GregNoel> (Man, I commented on this so long ago, I've almost completely forgotten what it was about.)
108 19:47:46 <sgk_> hell, you're right
109 19:48:04 <GregNoel> always {;-}
110 19:48:01 <sgk_> sounds like Cygwin, though, not MinGW
111 19:48:27 <sgk_> of course! we have to have at least *one* constant to rely on in the group... :-)
112 19:48:50 <Azverkan> my guess is that he has both msys and cygwin in his path
113 19:49:07 <sgk_> normal node-to-string translation is spitting them out as windows path
114 19:49:11 <Azverkan> before -mno-cygwin was added to GCC there was a lot of that
115 19:49:12 <sgk_> yeah, i think Brandon is right
116 19:49:16 <GregNoel> Since I don't use them, I don't know the difference between MSYS and Cygwin
117 19:49:32 <Azverkan> cygwin tries to give windows a posix style interface
118 19:49:36 <sgk_> Cygwin is evil evil evil
119 19:49:38 <Azverkan> msys tries to make native ports
120 19:49:58 <GregNoel> er, I wasn't asking, I was stating
121 19:50:19 <Azverkan> cygwin wouldn't be so bad if they were allowed to link against the now mostly unsupported posix runtime for the NT kernel
122 19:50:57 <sgk_> or if it had just used the "liberal in what you accept" philosophy and not gagged on native Windows path names
123 19:51:11 <sgk_> and if it didn't LIE about being able to support case sensitivity...
124 19:51:36 <sgk_> sorry, Cygwin has caused SCons more than a few hassles over the years
125 19:51:52 <sgk_> so my battle scars make me a little over-sensitive
126 19:52:26 <Azverkan> re the previous bug
127 19:52:29 <sgk_> back to 1500: WONTFIX
128 19:52:34 <Azverkan> the shim is the __builtin__.file = _scons_file?
129 19:52:38 <sgk_> yes
130 19:53:24 <GregNoel> wontfix closes an issue, so I like the idea
131 19:53:44 <sgk_> i can go ahead and write up the text and close it
132 19:53:50 <GregNoel> OK, I appreciate it
133 19:53:59 <Azverkan> either wontfix or invalid with a request for a test case
134 19:54:24 <GregNoel> 1502?
135 19:54:33 <sgk_> 1502: i like 1.x p4
136 19:54:51 <GregNoel> done
137 19:54:55 <sgk_> and eventually doing it with GetOption()
138 19:55:03 <GregNoel> (that was almost too easy)
139 19:55:20 <sgk_> statistically, *some* of them have to be...
140 19:55:28 <sgk_> 1504: research, VisualStudio, stevenknight
141 19:55:35 <GregNoel> done
142 19:55:51 <sgk_> 1508: research, VisualStudio, stevenknight
143 19:55:51 <GregNoel> although I think those are 'anytime'
144 19:56:00 <sgk_> in practice, true
145 19:56:16 <GregNoel> in database, true
146 19:56:24 <sgk_> if you want to change all VisualStudio tags to anytime, that'd be fine with me
147 19:56:29 <GregNoel> 1508, done
148 19:56:33 <sgk_> or else I'll do it one of these days
149 19:56:41 <GregNoel> exactly
150 19:56:50 <Azverkan> re 2124: can reproduce with or without the shim installed
151 19:56:55 <sgk_> ("in database, true" ? not sure i get the reference, but i like the concept)
152 19:57:16 <sgk_> Brandon: yow, 2124 with the shim is definitely something uninvestigated
153 19:57:25 <GregNoel> ('anytime' sorts just after 1.0.x right now, so it'll show up on your radar)
154 19:57:46 <sgk_> okay
155 19:58:11 <sgk_> that makes 2124 relatively high priority in my book
156 19:58:46 <GregNoel> Brandon, can you look at it? And report back next week?
157 19:58:54 <Azverkan> yep
158 19:59:09 <GregNoel> ok, let's just change the assignment, then
159 19:59:18 <GregNoel> er, owner
160 19:59:40 <sgk_> cool; many thanks
161 19:59:57 <GregNoel> 1516, speaking of colorization...
162 20:00:01 <sgk_> 1516: colorizer!
163 20:00:02 <sgk_> yes
164 20:01:09 <GregNoel> If I understand it better now, process spawning === convert to subprocess.
165 20:01:39 <GregNoel> As for colorization, I'm color-blind, so it's never made any sense to me.
166 20:01:40 <sgk_> yes
167 20:01:57 <Azverkan> for greg s/color/blink/
168 20:02:22 <GregNoel> So, do we have an issue to convert to subprocess?
169 20:02:34 <sgk_> no, there's a subprocess compatibility module now
170 20:02:45 <GregNoel> Azverkan, blink-blind? I don't get it.
171 20:03:08 <Azverkan> blinkizer
172 20:03:16 <sgk_> but hooking it into subprocess isn't really the right place
173 20:03:16 <GregNoel> Yes, but do we already have an issue to hang it on, or should we open one?
174 20:03:44 <Azverkan> I believe its also the same part of the multiprocessor buffering
175 20:03:52 <Azverkan> related to that is
176 20:04:03 <GregNoel> Ah, you're confused. This issue is to colorize the output; is there another issue for the subprocess conversion?
177 20:04:10 <Azverkan> some sort of mechanism for attaching to spawn output
178 20:04:29 <GregNoel> Yes, apparently subprocess allows that.
179 20:04:53 <GregNoel> It doesn't pump the output to a process, but you can capture the output.
180 20:05:56 <Azverkan> subprocess just makes popen less buggy on windows? afaik it doesn't offer anything above and beyond regular popen?
181 20:06:32 <sgk_> i think you're right re: underlying capability
182 20:06:42 <Azverkan> once you have the text stream out of popen or subprocess you need some way to install listeners
183 20:06:51 <sgk_> it's more about providing a more consistent, unified cross-platform interface
184 20:07:37 <sgk_> 1516: since I've already been in the middle of it, keep it with me
185 20:07:48 <sgk_> 2.x ?
186 20:07:54 <GregNoel> ok, both sides?
187 20:08:12 <Azverkan> agree with 2.x
188 20:08:15 <sgk_> sure
189 20:08:21 <GregNoel> colorize+subprocess?
190 20:08:33 <GregNoel> 2.x, what priority?
191 20:08:41 <sgk_> p3
192 20:08:53 <GregNoel> done
193 20:09:10 <GregNoel> Wow, that finishes this spreadsheet...
194 20:09:12 <sgk_> okay, i have to get going
195 20:09:18 <sgk_> same time next week?
196 20:09:26 <GregNoel> I should as well; cul?
197 20:09:34 <Azverkan> sure, later
198 20:09:37 <GregNoel> er, hang on...
199 20:10:13 <GregNoel> When shall we all meet again?
200 20:10:13 <GregNoel> In thunder, lightning, or in rain?
201 20:10:13 <GregNoel> Where the place? ... same time next week?
202 20:10:13 <GregNoel> Should we change the default time to this time?
203 20:10:30 <sgk_> you 20h00 PDT?
204 20:10:44 <sgk_> you mean 20h00 pdt?
205 20:10:49 <GregNoel> 19h00, same as you
206 20:11:34 <sgk_> yes, we've been using this time regularly enough it should become the default
207 20:11:48 <GregNoel> OK, I'll take care of that, too.
208 20:11:52 <Azverkan> quick question regarding the shim
209 20:11:57 <GregNoel> sure
210 20:12:00 <Azverkan> it opens with the inherit flag on
211 20:12:07 <Azverkan> and some amount of time later it toggles it off?
212 20:12:29 <GregNoel> ah, a race...
213 20:13:13 <sgk_> yes, since as far as i know, there isn't a way to open it with the inherit flag off
214 20:13:38 <sgk_> if i'm wrong, that'd be great
215 20:13:42 <GregNoel> it could explain the symptoms, even with the shim enabled.
216 20:13:40 <Azverkan> have to research that more and my wife wants to eat now, so later
217 20:13:56 <GregNoel> OK, cul
218 20:14:10 <sgk_> true
219 20:14:20 <sgk_> later
220 20:14:23 <sgk_> thanks, guys
221 20:14:29 <GregNoel> g'night
