-
-
Notifications
You must be signed in to change notification settings - Fork 309
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