IrcLog2009 02 18

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