IrcLog2009 02 18

William Deegan edited this page Jan 14, 2016 · 2 revisions
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 

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.