1. SCons
  2. Core
  3. SCons

Wiki

Clone wiki

SCons / BugParty / IrcLog2009-02-18

01:54:57  *      nait (i=[root@zans.eecs.umich.edu](mailto:root@zans.eecs.umich.edu)) has joined #scons 
17:24:40  *      stevenknight (n=[stevenkn@67.218.109.115](mailto:stevenkn@67.218.109.115)) has joined #scons 
17:31:08  *      [GregNoel](GregNoel) just got here; give me a sec 
17:31:32  *      [GregNoel](GregNoel) is no longer marked as being away 
17:31:58  *      Azverkan (n=[chatzill@99-52-200-251.lightspeed.snjsca.sbcglobal.net](mailto:chatzill@99-52-200-251.lightspeed.snjsca.sbcglobal.net)) has joined #scons 
17:32:06  <stevenknight> [GregNoel](GregNoel):  np, whenever you're ready 
17:32:13  <stevenknight> hey Azverkan 
17:32:22  <Azverkan>     hey 
17:33:06  <stevenknight> [GregNoel](GregNoel):  you probably saw, I went ahead and updated four of the 2004h2 issues that seemed like no-brainers 
17:34:05  <stevenknight> Azverkan:  hit undo in the spreadsheet, looks like your first "hey" got typed in that window... :-) 
17:34:22  <stevenknight> or at least I assume that's you in the upper-left cell 
17:35:32  <[GregNoel](GregNoel)>     OK, let's start; I'll catch up the rest as we go along 
17:35:44  <[GregNoel](GregNoel)>     1098? 
17:36:25  <[GregNoel](GregNoel)>     Azverkan, unfortunately not; my guess is that 3.0 support will be needed before the end of the year 
17:36:54  <Azverkan>     I mean can we make the assumption that unicode will only work in python3 
17:37:08  <stevenknight> I'd be okay with that, myself 
17:37:31  <Azverkan>     supporting 2x unicode and 3x uncode in the same codebase seeems non-trivial to me (unless I'm missing something obvious 
17:38:23  <[GregNoel](GregNoel)>     I dunno.  I've been looking at Utils.py a bit and it might be possible 
17:38:41  <Azverkan>     the one thing I couldn't figure out was how to handle string literals 
17:39:01  <Azverkan>     it seemed like a non-starter but I could be missing the obvious solution 
17:39:10  <[GregNoel](GregNoel)>     On the other hand, I've found a couple of places where manual fixes are currently required. 
17:40:29  <stevenknight> but then again i'm not running into Unicode issues 
17:40:29  <stevenknight> just supporting unicode seems non-trivial to me... :-) 
17:40:33  <stevenknight> Azverkan:  say more, what was the issue there? 
17:40:35  <stevenknight> just the u_ syntax? 
17:40:37  <[GregNoel](GregNoel)>     Still no obvious direction 
17:41:00  <stevenknight> yeah 
17:41:11  <Azverkan>     the behavior in 2.x vs 3.x is reversed 
17:41:22  <[GregNoel](GregNoel)>     There's a fixer for the cosmetic update; it's the cases where there's a real semantic difference that are the problem 
17:41:55  <stevenknight> but we don't have to supply identical behavior when run under Python 2.x vs. 3.x 
17:42:12  <[GregNoel](GregNoel)>     huh? 
17:42:25  <stevenknight> i.e., we can't be expect how we interpret a SConscript file to make up for Python changes, can we? 
17:42:22  <Azverkan>     it fails at the import level in python sometimes 
17:42:28  <nait> Hey guys.  I've been working with Greg on some of the Fixer issues.  I can chat for a bit. 
17:42:38  <stevenknight> hey nait 
17:42:40  <Azverkan>     a file that imports with  2. might throw unicode errors in 3 and vice versa 
17:43:23  <stevenknight> what areas besides string literals is that a problem? 
17:44:13  <[GregNoel](GregNoel)>     Um, user SConscript code is either 2.x or 3.x; when the _user_ upgrades is not our problem. 
17:44:28  <Azverkan>     thats the only case I found where you couldn't ljust create 2x and 3x code paths 
17:44:34  <stevenknight> okay 
17:44:56  <[GregNoel](GregNoel)>     Our problem is to be able to more-or-less do the same thing from the same code base, where... 
17:45:28  <[GregNoel](GregNoel)>     we work on the 2.x base and automatically convert it to the 3.x base 
17:44:59  <stevenknight> then I'd be okay with separate 2 vs. 3 modules containing a catalogue of string literals 
17:45:14  <stevenknight> underneath a layer that imports the right set of literals 
17:45:41  <stevenknight> but that's obvious enough that it probably doesn't solve all the problems...  what else? 
17:46:15  <[GregNoel](GregNoel)>     We have some code in strings; the obvious ones being in the test scripts 
17:46:40  <stevenknight> right 
17:47:04  <[GregNoel](GregNoel)>     I can imagine a startup shim that looks at the runtime and either runs 2.x base or 3.x base. 
17:47:24  <stevenknight> agreed 
17:47:49  <stevenknight> so are we morphing into saying that full unicode support only occurs in SCons when run under Python 3.x 
17:48:08  <stevenknight> and turning this into a "how do we support Python 3.x (and keep our development process sane)" problem? 
17:48:02  <[GregNoel](GregNoel)>     But cases like this issue will have to have code that looks dumb but works in both cases 
17:48:39  <[GregNoel](GregNoel)>     by calling a utility function, the same way that the strings transparency it handled now 
17:48:41  <stevenknight> hey, we have the "dumb code" thing down pretty well by now...  :-) 
17:49:13  <[GregNoel](GregNoel)>     {;-} 
17:49:26  <Azverkan>     the main problem being that all the shims slowly eat away at performance 
17:49:55  <stevenknight> right, but if it's really mainly string literals, I don't think we have lots of those on critical path 
17:50:07  <stevenknight> unless I'm overlooking something 
17:50:17  <Azverkan>     string literials i just the hardest problem to keep 2x and 3x code bases running in sync 
17:50:24  <[GregNoel](GregNoel)>     Yes, but they can go away eventually.  Think of isString() as an example. 
17:50:42  <stevenknight> right 
17:50:52  <stevenknight> so back to this issue... 
17:51:17  <Azverkan>     in 2x strings defaultl to ascii and you have to request unicode behavior, in 3x strings are default unicode 
17:51:36  <Azverkan>     so in 3x supporting unicode is more or less the "main" path throught he code 
17:51:18  <[GregNoel](GregNoel)>     Azverkan, that's what the fixers do; they automatically converts idioms.  You should be working with us on it... 
17:52:02  <Azverkan>     [GregNoel](GregNoel): just back from taiwan, you have a branch somewhere/ 
17:52:24  <[GregNoel](GregNoel)>     [PythonFixers](PythonFixers) in the wiki 
17:52:10  <nait> I might have missed something.  Do we want unicode with python2.x? 
17:53:14  <[GregNoel](GregNoel)>     nait, I do, for one, but that's gonna take some care 
17:52:28  <Azverkan>     supporting unicode in 2x is where the bulk of the work would need to be 
17:54:05  <[GregNoel](GregNoel)>     Azverkan, we already have utilities to make much of it transparent, but it will take some discipline to use them. 
17:54:36  <[GregNoel](GregNoel)>     (Well, not completely transparent, but not intrusive, at least.) 
17:55:11  <[GregNoel](GregNoel)>     But we're getting away from the issue, which is not Unicode transparency. 
17:55:38  <[GregNoel](GregNoel)>     The issue is one where the objects are really from different families. 
17:56:22  <[GregNoel](GregNoel)>     A code object will be `bytes` (not string) and the text will be 'Unicode' (not string) 
17:56:41  <[GregNoel](GregNoel)>     And ne'er the twain shall meet. 
17:57:12  <stevenknight> so...  anyone want to suggest a disposition for 1098? 
17:57:36  <[GregNoel](GregNoel)>     Sigh.  No change from last time. 
17:57:43  <Azverkan>     punt until 3.0 support goes in 
17:57:44  <stevenknight> and do we need some concrete next action item here for the larger 2.x => 3.x issue? 
17:57:56  <stevenknight> (i.e. something that's not already part of the Fixer work you're doing?) 
17:57:51  <[GregNoel](GregNoel)>     All I can suggest is a 'unicode' tag and try to look at it later. 
17:58:15  <stevenknight> okay, let's do that and move on 
17:58:38  <[GregNoel](GregNoel)>     OK, yes, I'll take it to the mailing lists 
17:58:43  <stevenknight> thnx 
17:59:00  <stevenknight> 1098:  gregnoel to write up for ML, done 
17:59:02  <stevenknight> 1107: 
17:59:22  <[GregNoel](GregNoel)>     Steven's comment is still out of date... 
17:59:49  <stevenknight> it is, isn't it 
18:00:25  <stevenknight> okay, updated 
18:00:48  <stevenknight> i'm suggesting 2.x p3 
18:00:54  <stevenknight> hopefully 2.1 since there's a patch 
18:01:03  <stevenknight> but it still needs the usual testing and doc 
18:01:15  <[GregNoel](GregNoel)>     I can't argue against p3, really, but I don't even know what a .pdb file does (and don't care; let's not get off on a side issue) 
18:01:22  <stevenknight> any objections? 
18:01:45  <[GregNoel](GregNoel)>     Seeing none, next. 
18:01:56  <stevenknight> okay 
18:01:59  <stevenknight> 1107:  2.x p3 done 
18:02:34  *      Azverkan I pray that someday microsoft will delete pdb files from their compiler :) 
18:02:02  <stevenknight> 8: 
18:03:33  <[GregNoel](GregNoel)>     Even though there's a common patch, I see them as separate. 
18:03:58  <[GregNoel](GregNoel)>     But I'll go with p3 if others think that's better. 
18:04:23  <stevenknight> [GregNoel](GregNoel):  "them" == issues 8 and 1107? 
18:04:43  <[GregNoel](GregNoel)>     stevenknight, yes 
18:05:20  <nait> (s/Options/Variables/ for the latest versions of scons) 
18:05:37  <stevenknight> 2.x p3, i can take it if no one else is itching to 
18:05:48  <[GregNoel](GregNoel)>     OK, works for me 
18:05:52  <stevenknight> done 
18:06:25  <stevenknight> 2310: 
18:06:45  <[GregNoel](GregNoel)>     2310, looneycyborg got him to use absolute paths. 
18:07:02  <stevenknight> ah 
18:07:07  <stevenknight> yeah, that would work around it 
18:07:28  <stevenknight> does it really seem to you like he was trying to do something that shouldn't work? 
18:08:16  <stevenknight> if so, I'm okay with INVALID 
18:08:24  <[GregNoel](GregNoel)>     I couldn't tell.  There are quite a number of things going on and the SConstruct was just too big to understand. 
18:08:27  <Azverkan>     its related to chdir() I think 
18:08:36  <stevenknight> ah, I could see that 
18:09:10  <[GregNoel](GregNoel)>     I asked loony for a smaller test case, and he put it on IRC while I was gone; I haven't looked at it yet 
18:09:03  <stevenknight> okay, how about INVALID with the usual "reopen with a test case if necessary" message 
18:09:13  <stevenknight> he won't, but it might help someone else who stumbles on the issue in the future 
18:09:32  <[GregNoel](GregNoel)>     OK, works, but I'll check the test case before I do 
18:09:40  <stevenknight> done 
18:10:02  <stevenknight> 2288:  could use a packaging guru here... 
18:10:07  <stevenknight> and 2289 
18:10:19  <nait> I just looked at it a little bit, and it seems to remind me of a problem I had with my multiple variant stuff that I posted a while ago. Basically, there's only one FS object, but you want two working directories. 
18:11:35  <[GregNoel](GregNoel)>     2289, stevenknight, concur with your comment 
18:12:20  <stevenknight> do we have a likely packaging guru anywhere?  can we ask this guy? 
18:12:40  <[GregNoel](GregNoel)>     nait, still absorbing your statement... 
18:13:02  <nait> greg, I could be wrong, since there's a lot of code there to understand. 
18:13:48  <stevenknight> nait:  I'd like to understand off-line how multiple FS objects might have solved your problem 
18:13:59  <[GregNoel](GregNoel)>     agree 
18:14:10  <stevenknight> can you send me something? 
18:14:16  <[GregNoel](GregNoel)>     cc me? 
18:14:32  <Azverkan>     directory globbng is the only issue I'm aware of 
18:15:02  <nait> Actually most of it was in that thread I started a few weeks ago. 
18:15:02  <[GregNoel](GregNoel)>     Yeah, but dir.Glob() mostly works 
18:15:26  <[GregNoel](GregNoel)>     I have an issue on my plate to remove that "mostly" and document it. 
18:15:54  <nait> I'll try to read this code and understand it better before I conclude that my statement has merit.  I was acutally trying to use multiple [VarintDir](VarintDir)()s at once.  That is definitely not supported. 
18:16:05  <nait> (without extra FS objects being created manually.) 
18:16:06  <stevenknight> nait:   understood 
18:16:46  <stevenknight> extra FS objects probably aren't the ultimate right answer, because it would probably cause other problems in the current architecture 
18:16:46  <[GregNoel](GregNoel)>     Let's close 2289 and leave 2288 for next time. 
18:17:13  <stevenknight> but using it to understand your case from that perspective would be helpful for other design discussions going on 
18:17:46  <stevenknight> so don't hesitate to raise the issue 
18:18:00  <stevenknight> [GregNoel](GregNoel):  concur re: 2289 and 2288 
18:17:52  <stevenknight> < 1 minute until my shuttle stop 
18:18:03  <[GregNoel](GregNoel)>     rats... 
18:18:06  <stevenknight> yeah 
18:18:13  <[GregNoel](GregNoel)>     We didn't manage much 
18:18:20  <[GregNoel](GregNoel)>     Maybe tomorrow? 
18:18:21  <stevenknight> yeah, rough set of issues tonight 
18:18:24  <stevenknight> i'm game 
18:18:34  <stevenknight> okay, later 
18:18:38  <[GregNoel](GregNoel)>     bye 
18:18:36  *      stevenknight has quit ("Leaving") 
19:34:58  *      [GregNoel](GregNoel) has been marked as being away 

Updated