-
-
Notifications
You must be signed in to change notification settings - Fork 309
IrcLog2008 08 04
William Deegan edited this page Jan 14, 2016
·
2 revisions
19:21:47 <sgk_> 2124:
19:22:16 <sgk_> brandon, it's the open filehandles thing?
19:22:21 <Azverkan> yeah
19:22:23 <[GregNoel](GregNoel)> I think he's getting the errors because the shims aren't being installed
19:22:33 <Azverkan> I reproduced the bug localluy
19:22:43 <[GregNoel](GregNoel)> With the shims?
19:22:57 <Azverkan> I haven't figured out whether I can reproduce the problem with Microsoft's CL.EXE yet
19:23:03 <Azverkan> err wihtout
19:23:10 <Azverkan> it might be something specific to what they are doing
19:23:17 <sgk_> if it's without then it's a known issue
19:23:26 <sgk_> and we need to fix the other bug where the message isn't getting printed
19:23:49 <[GregNoel](GregNoel)> Yes, the fact that he found the bug suggests that he should have been getting the message.
19:23:51 <sgk_> i also think we probably need to make those shims Yet Another configurable item
19:24:15 <[GregNoel](GregNoel)> Why would you want to turn them off?
19:24:20 <sgk_> Carsten's message on the ML about compiler output getting lost when redirected is because of the shims, I think
19:24:28 <Azverkan> I think it might only applicable to applications that [CreateFile](CreateFile) with non default filesharing params, but I need to narrow it down more yet
19:25:21 <sgk_> but that would need to be confirmed
19:25:30 <Azverkan> whats the "shim"?
19:25:33 <sgk_> that aside, where does it leave us for 2124?
19:25:45 <[GregNoel](GregNoel)> Hmmm... Sounds to me like Brandon should be working on it
19:25:58 <Azverkan> I think its a real bug that probably won't get fixed in the 1.0.x timeframe
19:25:59 <sgk_> we replace the Python open() call (<ins>builtin</ins>.open()) with our own wrapper that calls the real underlying open()
19:26:00 <[GregNoel](GregNoel)> shim ==> code in Platform/win32 that replaces open() and file()
19:26:19 <sgk_> and then calls the win32 api to supress the filehandle inheritance
19:27:19 <Azverkan> can verify while we move on to other bugs
19:27:29 <sgk_> okay, cool
19:27:29 <[GregNoel](GregNoel)> 2124: Brandon, research?
19:27:34 <sgk_> done
19:27:51 <[GregNoel](GregNoel)> We'll see if he comes up with anything before we go
19:27:50 <sgk_> 2155:
19:28:10 <sgk_> okay
19:28:18 <[GregNoel](GregNoel)> 2155: consensus invalid
19:28:23 <sgk_> 2155: sounds like we agree to deprecate it
19:29:07 <sgk_> guess that would mean holding this open for now ut changing it to track the eventual deprecation?
19:29:12 <[GregNoel](GregNoel)> OK, I'll untangle it; probably put a note in 2126
19:29:29 <sgk_> cool, thanks
19:29:26 <Azverkan> is there a naming convention for internal vs external functions?
19:29:33 <sgk_> not really
19:29:53 <sgk_> the closest we have is that, in general, public functions have [CamelCase](CamelCase) spelling
19:30:02 <[GregNoel](GregNoel)> External usually have caps; internal not, but it's not completely reliable
19:30:07 <sgk_> but there are plenty of things like subst() that have gained currency
19:30:34 * sgk_ wishes he had [GregNoel](GregNoel)'s gift for brevity
19:30:53 <sgk_> i always take a lot of extra words to say things...
19:30:56 * [GregNoel](GregNoel) can't type fast, so he learned to be brief
19:31:28 <sgk_> okay, 2155: [GregNoel](GregNoel) to handle
19:31:46 <[GregNoel](GregNoel)> done
19:31:57 <[GregNoel](GregNoel)> 2157?
19:32:20 <sgk_> 2157: fixing ^C in configure context in general is WONTFIX
19:32:42 <sgk_> but making sure we don't record an interrupt as a cached failure is... 1.x p3?
19:33:07 <[GregNoel](GregNoel)> it's probably the same thing; a partial store of something
19:33:49 <[GregNoel](GregNoel)> I'll go with looking at it again as 1.x p3
19:33:58 <sgk_> done
19:34:16 <[GregNoel](GregNoel)> 2158?
19:34:19 <sgk_> 2158: consensus 1.0.1 p4 anybody
19:34:25 <[GregNoel](GregNoel)> done
19:34:39 <[GregNoel](GregNoel)> so who?
19:34:41 <sgk_> OMG we got through the current issues
19:34:54 <[GregNoel](GregNoel)> only four!
19:35:03 <sgk_> and in only half an hour!
19:35:14 <[GregNoel](GregNoel)> true.
19:35:20 * sgk_ is feeling full of piss and vinegar
19:35:29 <sgk_> on to the backlog!
19:35:36 <[GregNoel](GregNoel)> Should we assign someone when we re-triage?
19:35:44 <sgk_> for 2158?
19:35:47 <[GregNoel](GregNoel)> yes
19:36:05 <sgk_> who?
19:36:32 <[GregNoel](GregNoel)> Anyone: you, me, Gary, Brandon. It's one line of code!
19:36:42 <sgk_> me
19:36:45 <[GregNoel](GregNoel)> done
19:37:58 <sgk_> well, let's at least kill those last 2006H2 bugs
19:38:24 <[GregNoel](GregNoel)> yes, just getting set up. My network is slow today
19:38:32 <[GregNoel](GregNoel)> 1490
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)
19:39:40 <sgk_> Brandon: like with -j3 you can get ccclll...eeexxxeee ///fffooo
19:39:42 <sgk_> that sort of thing?
19:40:08 <Azverkan> all sorts of extended ascii characters and whatnot
19:40:28 <Azverkan> depends what code page you have setup
19:40:29 <sgk_> yeah, we need something that slurps up that stuff and controls the output
19:40:45 <sgk_> 1490: boy, do i wish we had an installer guru
19:40:53 <[GregNoel](GregNoel)> that's the colorizer issue
19:41:02 <[GregNoel](GregNoel)> 1490, yes
19:41:09 <sgk_> agreed re: colorizer
19:41:26 <[GregNoel](GregNoel)> As I said in the spreadsheet, I have no clue.
19:41:42 <[GregNoel](GregNoel)> you two have to work it out
19:42:03 <sgk_> let's say 1.x p3 (my favorite)
19:42:15 <sgk_> since we have no one immediate to research it
19:42:33 <[GregNoel](GregNoel)> Brandon? If you agree, I'll go along
19:42:38 <sgk_> i can try to recruit someone who knows about installation
19:43:03 <sgk_> i have a couple of people in mind who might be suitable
19:43:16 <[GregNoel](GregNoel)> And an AIX guru, and a Solaris guru, and ...
19:43:33 <sgk_> agreed
19:44:04 <Azverkan> 1490 we are using the stock installer
19:44:21 <Azverkan> I'd say wontfix with use a different install method?
19:44:38 <sgk_> right, and it's getting clearer that stock distutils installer isn't up what we need
19:45:10 <[GregNoel](GregNoel)> I like wontfix; it closes an issue
19:45:12 <sgk_> how about 1.x p3 me
19:45:33 <[GregNoel](GregNoel)> OK, although you've got too much work
19:45:34 <sgk_> eh, i don't like losing input for when someone takes a look at it
19:45:44 <sgk_> yeah, but i'd take this with the intent of passing it off
19:45:48 <sgk_> once i find someone
19:45:51 <[GregNoel](GregNoel)> works for me
19:45:59 <sgk_> done
19:46:03 <[GregNoel](GregNoel)> 1.x p3, then
19:46:39 <sgk_> 1500: sounds like it might be a generic path interpretation issue
19:46:44 <sgk_> research, who?
19:46:50 <[GregNoel](GregNoel)> I think 1500 is a mingw v. native issue
19:47:34 <[GregNoel](GregNoel)> (Man, I commented on this so long ago, I've almost completely forgotten what it was about.)
19:47:46 <sgk_> hell, you're right
19:48:04 <[GregNoel](GregNoel)> always {;-}
19:48:01 <sgk_> sounds like Cygwin, though, not MinGW
19:48:27 <sgk_> of course! we have to have at least *one* constant to rely on in the group... :-)
19:48:50 <Azverkan> my guess is that he has both msys and cygwin in his path
19:49:07 <sgk_> normal node-to-string translation is spitting them out as windows path
19:49:11 <Azverkan> before -mno-cygwin was added to GCC there was a lot of that
19:49:12 <sgk_> yeah, i think Brandon is right
19:49:16 <[GregNoel](GregNoel)> Since I don't use them, I don't know the difference between MSYS and Cygwin
19:49:32 <Azverkan> cygwin tries to give windows a posix style interface
19:49:36 <sgk_> Cygwin is evil evil evil
19:49:38 <Azverkan> msys tries to make native ports
19:49:58 <[GregNoel](GregNoel)> er, I wasn't asking, I was stating
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
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
19:51:11 <sgk_> and if it didn't LIE about being able to support case sensitivity...
19:51:36 <sgk_> sorry, Cygwin has caused SCons more than a few hassles over the years
19:51:52 <sgk_> so my battle scars make me a little over-sensitive
19:52:26 <Azverkan> re the previous bug
19:52:29 <sgk_> back to 1500: WONTFIX
19:52:34 <Azverkan> the shim is the <ins>builtin</ins>.file = _scons_file?
19:52:38 <sgk_> yes
19:53:24 <[GregNoel](GregNoel)> wontfix closes an issue, so I like the idea
19:53:44 <sgk_> i can go ahead and write up the text and close it
19:53:50 <[GregNoel](GregNoel)> OK, I appreciate it
19:53:59 <Azverkan> either wontfix or invalid with a request for a test case
19:54:24 <[GregNoel](GregNoel)> 1502?
19:54:33 <sgk_> 1502: i like 1.x p4
19:54:51 <[GregNoel](GregNoel)> done
19:54:55 <sgk_> and eventually doing it with [GetOption](GetOption)()
19:55:03 <[GregNoel](GregNoel)> (that was almost too easy)
19:55:20 <sgk_> statistically, *some* of them have to be...
19:55:28 <sgk_> 1504: research, [VisualStudio](VisualStudio), stevenknight
19:55:35 <[GregNoel](GregNoel)> done
19:55:51 <sgk_> 1508: research, [VisualStudio](VisualStudio), stevenknight
19:55:51 <[GregNoel](GregNoel)> although I think those are 'anytime'
19:56:00 <sgk_> in practice, true
19:56:16 <[GregNoel](GregNoel)> in database, true
19:56:24 <sgk_> if you want to change all [VisualStudio](VisualStudio) tags to anytime, that'd be fine with me
19:56:29 <[GregNoel](GregNoel)> 1508, done
19:56:33 <sgk_> or else I'll do it one of these days
19:56:41 <[GregNoel](GregNoel)> exactly
19:56:50 <Azverkan> re 2124: can reproduce with or without the shim installed
19:56:55 <sgk_> ("in database, true" ? not sure i get the reference, but i like the concept)
19:57:16 <sgk_> Brandon: yow, 2124 with the shim is definitely something uninvestigated
19:57:25 <[GregNoel](GregNoel)> ('anytime' sorts just after 1.0.x right now, so it'll show up on your radar)
19:57:46 <sgk_> okay
19:58:11 <sgk_> that makes 2124 relatively high priority in my book
19:58:46 <[GregNoel](GregNoel)> Brandon, can you look at it? And report back next week?
19:58:54 <Azverkan> yep
19:59:09 <[GregNoel](GregNoel)> ok, let's just change the assignment, then
19:59:18 <[GregNoel](GregNoel)> er, owner
19:59:40 <sgk_> cool; many thanks
19:59:57 <[GregNoel](GregNoel)> 1516, speaking of colorization...
20:00:01 <sgk_> 1516: colorizer!
20:00:02 <sgk_> yes
20:01:09 <[GregNoel](GregNoel)> If I understand it better now, process spawning === convert to subprocess.
20:01:39 <[GregNoel](GregNoel)> As for colorization, I'm color-blind, so it's never made any sense to me.
20:01:40 <sgk_> yes
20:01:57 <Azverkan> for greg s/color/blink/
20:02:22 <[GregNoel](GregNoel)> So, do we have an issue to convert to subprocess?
20:02:34 <sgk_> no, there's a subprocess compatibility module now
20:02:45 <[GregNoel](GregNoel)> Azverkan, blink-blind? I don't get it.
20:03:08 <Azverkan> blinkizer
20:03:16 <sgk_> but hooking it into subprocess isn't really the right place
20:03:16 <[GregNoel](GregNoel)> Yes, but do we already have an issue to hang it on, or should we open one?
20:03:44 <Azverkan> I believe its also the same part of the multiprocessor buffering
20:03:52 <Azverkan> related to that is
20:04:03 <[GregNoel](GregNoel)> Ah, you're confused. This issue is to colorize the output; is there another issue for the subprocess conversion?
20:04:10 <Azverkan> some sort of mechanism for attaching to spawn output
20:04:29 <[GregNoel](GregNoel)> Yes, apparently subprocess allows that.
20:04:53 <[GregNoel](GregNoel)> It doesn't pump the output to a process, but you can capture the output.
20:05:56 <Azverkan> subprocess just makes popen less buggy on windows? afaik it doesn't offer anything above and beyond regular popen?
20:06:32 <sgk_> i think you're right re: underlying capability
20:06:42 <Azverkan> once you have the text stream out of popen or subprocess you need some way to install listeners
20:06:51 <sgk_> it's more about providing a more consistent, unified cross-platform interface
20:07:37 <sgk_> 1516: since I've already been in the middle of it, keep it with me
20:07:48 <sgk_> 2.x ?
20:07:54 <[GregNoel](GregNoel)> ok, both sides?
20:08:12 <Azverkan> agree with 2.x
20:08:15 <sgk_> sure
20:08:21 <[GregNoel](GregNoel)> colorize+subprocess?
20:08:33 <[GregNoel](GregNoel)> 2.x, what priority?
20:08:41 <sgk_> p3
20:08:53 <[GregNoel](GregNoel)> done
20:09:10 <[GregNoel](GregNoel)> Wow, that finishes this spreadsheet...
20:09:12 <sgk_> okay, i have to get going
20:09:18 <sgk_> same time next week?
20:09:26 <[GregNoel](GregNoel)> I should as well; cul?
20:09:34 <Azverkan> sure, later
20:09:37 <[GregNoel](GregNoel)> er, hang on...
20:10:13 <[GregNoel](GregNoel)> When shall we all meet again?
20:10:13 <[GregNoel](GregNoel)> In thunder, lightning, or in rain?
20:10:13 <[GregNoel](GregNoel)> Where the place? ... same time next week?
20:10:13 <[GregNoel](GregNoel)> Should we change the default time to this time?
20:10:30 <sgk_> you 20h00 PDT?
20:10:44 <sgk_> you mean 20h00 pdt?
20:10:49 <[GregNoel](GregNoel)> 19h00, same as you
20:11:34 <sgk_> yes, we've been using this time regularly enough it should become the default
20:11:48 <[GregNoel](GregNoel)> OK, I'll take care of that, too.
20:11:52 <Azverkan> quick question regarding the shim
20:11:57 <[GregNoel](GregNoel)> sure
20:12:00 <Azverkan> it opens with the inherit flag on
20:12:07 <Azverkan> and some amount of time later it toggles it off?
20:12:29 <[GregNoel](GregNoel)> ah, a race...
20:13:13 <sgk_> yes, since as far as i know, there isn't a way to open it with the inherit flag off
20:13:38 <sgk_> if i'm wrong, that'd be great
20:13:42 <[GregNoel](GregNoel)> it could explain the symptoms, even with the shim enabled.
20:13:40 <Azverkan> have to research that more and my wife wants to eat now, so later
20:13:56 <[GregNoel](GregNoel)> OK, cul
20:14:10 <sgk_> true
20:14:20 <sgk_> later
20:14:23 <sgk_> thanks, guys
20:14:29 <[GregNoel](GregNoel)> g'night