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