[01:20] pedronis (~Samuele_P@c-368b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050317]"
----- silence for 55 minutes ----- [02:15] cfbolz (~cfbolz@hdlb-3e34200a.pool.mediaWays.net) joined #pypy.
[02:15] <cfbolz> hi holger!
[02:16] <cfbolz> Still awake?
[02:16] jamwt (jamwt@count.jamwt.com) left #pypy.
[02:18] cfbolz (~cfbolz@hdlb-3e34200a.pool.mediaWays.net) left irc: Remote closed the connection
----- silence for 39 minutes ----- [02:57] <stakkars_> hpk: oops?
[02:59] <stakkars_> then we obviously don't have enough good tests. They all pass.
[03:03] <stakkars_> hpk: sorry, that thing doesn't work for me at all:
[03:04] <stakkars_> File "D:\pypy\dist\py\path\svn\wccommand.py", line 465, in __init__
[03:04] <stakkars_> self.kind = d['nodekind'] == 'directory' and 'dir' or d['nodekind']
[03:04] <stakkars_> KeyError: 'nodekind'
[03:15] <stakkars_> since it doesn't run on my machine, I'd like to ask you to find out which file is causing this problem.
[03:15] stakkars_ (pixsnsr@i528C1277.versanet.de) left irc: "bye"
----- silence for 37 minutes ----- [03:52] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: Read error: 113 (No route to host)
----- silence for 3 hr and 8 minutes ----- [07:00] bbiow (bbiow@82.145.232.220) joined #pypy.
[07:00] bbiow (bbiow@82.145.232.220) left #pypy.
[07:05] idnar (mithrandi@idnar.user) left irc: Read error: 60 (Operation timed out)
[07:05] sanxiyn (~tinuviel@211.104.100.115) joined #pypy.
----- silence for 1 hr and 59 minutes ----- [09:04] idnar (mithy@idnar.user) joined #pypy.
----- silence for 1 hr and 44 minutes ----- [10:48] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.
[10:48] <cfbolz> hi!
[10:49] <cfbolz> hpk: are you there?
----- silence for 20 minutes ----- [11:09] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
[11:14] <hpk> cfbolz: yes, just got in
[11:16] <cfbolz> I *don't* want you to enable oldjava for pypy-dev
[11:16] <hpk> cfbolz: ok, i somehow guessed so :-)
[11:16] <cfbolz> it's an old legacy email adress
[11:16] <cfbolz> but I don't get the stupid gmx to set cfbolz as the default adress
[11:17] <cfbolz> and if I'm not awake enough I forget to check this before sending a mail :-)
[11:23] <hpk> i see
[11:23] Action: hpk is elsewhere
[11:31] idnar (mithy@idnar.user) left irc: Nick collision from services.
[11:32] idnar_ (mithy@idnar.user) joined #pypy.
[11:43] stakkars (~tismer@82.144.60.19) joined #pypy.
----- silence for 17 minutes ----- [12:00] <stakkars> hi all
[12:00] ludal (~ludal@logilab.net2.nerim.net) left irc: Remote closed the connection
[12:01] <cfbolz> hi!
[12:01] <stakkars> haudi
[12:02] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
[12:02] <cfbolz> how's it goin'?
[12:04] <stakkars> well, quite fine. Modulo the problems which I can't solvealone :-)
[12:04] <cfbolz> I won't be much help probably :-)
[12:04] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[12:05] <stakkars> moin
[12:15] <pedronis> hi
[12:16] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
[12:31] <pedronis> stakkkars: the failure in flow space is from a change by seo for 2.2 compatibility I think
[12:43] <pedronis> stakkars:
[12:52] idnar_ (mithy@idnar.user) left irc: Client Quit
----- silence for 17 minutes ----- [13:09] <stakkars> pedronis: fine that it wasn't me :)
[13:20] idnar (mithy@idnar.user) joined #pypy.
[13:35] <cfbolz> I have a question concerning exceptions:
[13:36] <cfbolz> Shouldn't 'raise IndexError("Index out of range")' and 'raise IndexError, "Index out of range"' do the same thing?
[13:36] <pedronis> the flow space does not normalize
[13:37] <pedronis> so the second form can confuse the annotator
[13:37] <cfbolz> So it's enough to support the first?
[13:38] <pedronis> yes, supporint raise Exc and raise Exc(...) should be enough
[13:38] <cfbolz> Good. Otherwise I would have to do the normalization in genllvm, which would be annoying
[13:48] ludal (~ludal@logilab.net2.nerim.net) left irc: "Download Gaim: http://gaim.sourceforge.net/";
[13:48] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
[13:52] ludal (~ludal@logilab.net2.nerim.net) left irc: Client Quit
[13:52] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
[14:04] <stakkars> pedronis, cfbolz: no, this is not correct!
[14:05] <pedronis> what is not correct?
[14:05] <stakkars> raise Exc,value must be supported, or we won't pass certain tests.
[14:06] <pedronis> by PyPy, yes
[14:06] <stakkars> see my comment in sys.exit
[14:06] <pedronis> we are talking about annotated RPython
[14:07] <stakkars> ah, you mean this doesn't apply to the translator
[14:07] <pedronis> right now, the flow space + annotator have a hard time doing the right thing with that case
[14:10] <pedronis> what we could do is have the flow space generate the same thing as for raise Exc,_ -> raise Exc(_)
[14:11] <stakkars> but that would be one normalize_exception less, right?
[14:12] <pedronis> I mean flow space normalize_exception should put some simple_call into graph for that case
[14:13] <stakkars> a simple_call which does the normalisation?
[14:14] <pedronis> the problem is doing the right both for raise Exc, args vs. raise Exc,Exc(args)
[14:16] <pedronis> I suspect that at some point the code in normalize_excpetion as it is in the flow space will bite us
[14:23] <cfbolz> Well, I'll stick to the easy cases right now (raise Exc and raise Exc(...))
[14:24] <cfbolz> and wait untill the annotator supports the rest :-)
[14:33] <pedronis> the problem is not the annotator, is that is not well defined what is responsible for normalization and when
[14:33] <cfbolz> yes. I know. That
[14:35] <cfbolz> s/That/
[14:36] <cfbolz> But the generators should not be responsible for it, right?
[14:36] <cfbolz> (generators meaning genc, genllvm...)
[14:36] <stakkars> I don't think so.
[14:37] <pedronis> well, but they probably should for the case raise Exc
[14:38] <pedronis> otherwise I expect at some point some except E,e:
[14:38] <pedronis> to get null in e
[14:38] <cfbolz> yes, that's one of my problems right now
[14:39] <stakkars> I don't get the problem right now. if I have two simple functions like
[14:39] <stakkars> >>> def f1():
[14:39] <stakkars> ... raise ValueError, 42
[14:39] <stakkars> ...
[14:39] <stakkars> >>> def f2():
[14:39] <stakkars> ... raise ValueError(42)
[14:39] <stakkars> then what we have is this:
[14:39] <stakkars> >>> dis.dis(f1)
[14:39] <stakkars> 2 0 LOAD_GLOBAL 0 (ValueError)
[14:39] <stakkars> 3 LOAD_CONST 1 (42)
[14:39] <stakkars> 6 RAISE_VARARGS 2
[14:39] <stakkars> 9 LOAD_CONST 0 (None)
[14:39] <stakkars> 12 RETURN_VALUE
[14:39] <stakkars> >>> dis.dis(f2)
[14:39] <stakkars> 2 0 LOAD_GLOBAL 0 (ValueError)
[14:39] <stakkars> 3 LOAD_CONST 1 (42)
[14:39] <stakkars> 6 CALL_FUNCTION 1
[14:39] <stakkars> 9 RAISE_VARARGS 1
[14:39] <stakkars> 12 LOAD_CONST 0 (None)
[14:39] <stakkars> 15 RETURN_VALUE
[14:39] <stakkars> that is just one call_function more. Where is the problem?
[14:40] <pedronis> well, for example that if both those style of raises are in a function with a except ValueError, e:
[14:41] <pedronis> the annotator will unify 42 and SomeInst(ValueError) -> SomeObject
[14:41] <pedronis> notice that we were discussing raise ValueError
[14:42] <pedronis> without value also
[14:42] <stakkars> ah, oh I see!
[14:42] <stakkars> >>> dis.dis(f3)
[14:42] <stakkars> 2 0 LOAD_GLOBAL 0 (ValueError)
[14:42] <stakkars> 3 RAISE_VARARGS 1
[14:42] <stakkars> 6 LOAD_CONST 0 (None)
[14:42] <stakkars> 9 RETURN_VALUE
[14:43] <pedronis> yes wich right now is propagate as ValueError,None by the flow space
[14:43] <pedronis> so the discussion about the risk of except Exc,e: to result in e being NULL or null ...
[14:44] <stakkars> aua
[14:44] <cfbolz> In this case I would have to generate a ValueError instance
[14:45] <pedronis> I think we have not been bitten by this because for geninterp I think CPython still at some normalize for us
[14:45] <stakkars> how about a split here? treating raise_varargs completely different for the number of agrs?
[14:45] <pedronis> s/at some/at some point
[14:45] <pedronis> or maybe we don't have a test
[14:46] <stakkars> in geninterp, I'm adding the normalization by myself.
[14:46] <pedronis> ah
[14:46] <cfbolz> I tried to avoid doing that.
[14:46] <stakkars> because I ran exactly into this problem.
[14:48] <cfbolz> I can detect the 'raise ValueError' case by checking whether the link to the exceptblock has Constant(None) as a second argument, right?
[14:48] <stakkars> I anyway have to do special things, different from the other generators. For
[14:49] <pedronis> stakkars: do you normalize on raise or on except
[14:49] <stakkars> instance, I need to capture OperationError, and then dispatch on the wrapped exception etc.
[14:49] <stakkars> let me see...
[14:49] arigo (~arigo@stups.cs.uni-duesseldorf.de) joined #pypy.
[14:49] <pedronis> because for some code when you hava a raise and except in a same function
[14:50] <pedronis> you can get normal links entering the except block with unnormalized stuff
[14:50] <stakkars> # Since we only have OperationError, we need to select:
[14:50] <stakkars> yield "except %s, e:" % (self.nameof(OperationError),)
[14:50] <stakkars> yield " e.w_type, e.w_value, _ign = space.unpacktuple("
[14:50] <stakkars> yield " space.normalize_exception(e.w_type, e.w_value, space.w_None), 3)"
[14:50] <stakkars> I think this is exactly what ceval does.
[14:51] <pedronis> yes, but as I said for some raise except combinations in the same function you will not go through except
[14:52] <stakkars> the exception will stay unnormalized until it is caught by some except clause elsewhere, yes.
[14:53] <pedronis> no the exception unnormalized will enter the except suite without having passed through an except
[14:55] <stakkars> ok, I'm probably the wrong person since I don't get it :-/
[14:55] <pedronis> for example this code:
[14:55] <pedronis> def f():
[14:55] <pedronis> try:
[14:55] <pedronis> raise ValueError
[14:56] <pedronis> except ValueError,e:
[14:56] <pedronis> return None
[14:56] <pedronis> sorry: return e
[14:56] <pedronis> is transformed into return None
[14:56] <pedronis> by the flowgraph
[14:56] <pedronis> wich is the wrong thing
[14:57] <cfbolz> so essentially only raise Exc(args) is safe at the moment.
[14:57] <pedronis> yes, sort of
[14:57] <pedronis> this is a kind of degenerate case
[14:58] <pedronis> (I just tried it now, the case I encountered were more involved)
[14:58] <pedronis> but it shows that the flow graph punting about normalization is probably the wrong thing
[15:00] <arigo> I'm wondering if the annotation is good enough now
[15:00] <arigo> if so, the flow graph could do the full normalization
[15:00] <arigo> and the annotation would simplify it away in common cases
[15:00] <pedronis> I don't follow, the annotator does not simplify
[15:03] <pedronis> arigo: what kind of simplification have you in mind?
[15:03] <arigo> the ones where the annotator figures out that some branches are never followed
[15:03] <arigo> if the flow graph contains all the checking logic of normalization,
[15:04] <arigo> then it's necessary that most of it goes away,
[15:04] <arigo> which the annotator can do by tracking types carefully
[15:04] <pedronis> but there's nothing like that in the annotator
[15:04] <pedronis> is the flowgraph constant computations that remove things right now
[15:04] <arigo> not only:
[15:05] <arigo> transform.py (which runs after the annotator) will prune branches not followed by the annotator
[15:05] <arigo> and then remove operations like checks whose results are no longer useful
[15:05] <pedronis> ah
[15:06] <pedronis> well, we can try, anyway right now the flow graph is doing the wrong thing
[15:06] <pedronis> and the successive phases cannot even recover from that
[15:07] <pedronis> I mean the f returning None above
[15:07] <arigo> yes
[15:07] <arigo> the following example seems to work:
[15:07] <arigo> def fn(x):
[15:07] <arigo> y = ValueError()
[15:07] <arigo> if isinstance(y, ValueError):
[15:07] <arigo> return x+1
[15:07] <arigo> else:
[15:07] <arigo> return x+2
[15:07] <arigo> t.annotate([int]).simplify() -> only the call to ValueError and the "add 1" remain
[15:08] <pedronis> yes, the annotator is trying to do a goo job about isintance and now also type(.) is guards
[15:09] <arigo> ah, apparently I have to go and sign by employment contract now (finally!!)
[15:09] <arigo> s/by/my
[15:09] <pedronis> :)
[15:09] <arigo> see you in a minute :-)
[15:22] arre (ac@ratthing-b3fa.strakt.com) joined #pypy.
----- silence for 17 minutes ----- [15:39] Action: arigo is now paid for PyPy work :-)
[15:41] <cfbolz> yay
[15:42] <cfbolz> Are you working for the Uni Duesseldorf?
[15:43] <arigo> yes
[15:43] <cfbolz> Did you have to swear on the "Freiheitlich demokratische Grundordnung"?
[15:43] <cfbolz> :-)
[15:44] <arigo> not sure exactly -- I did indeed have to sign a Niederschrift (strange thing but I've seen stranger)
[15:45] <arigo> "Ich gelobe: Ich werbe meine Dienstobliegenheiten gewissenhaft erfuellen und das Grundgesetz fuer die Bundesrepublik Deutschland sowie die Gesetze wahren."
[15:45] <cfbolz> That's what I meant.
[15:45] <arigo> ok
[15:46] <arigo> basically, "I swear I won't do bad things to Germany", right?
[15:46] <cfbolz> Yes.
[15:47] <cfbolz> a few years ago some people weren't allowed to work as teaches because they went to some demonstrations. The reasoning was that they had demonstrated that they wouldn't fullfill this oath.
[15:48] <cfbolz> s/teaches/teachers
[15:48] <arigo> argh.
[15:50] <cfbolz> let's hope that this was the dark past :-)
[15:53] <thingie25> arigo: Are you working on PyPy fulltime?
[15:55] <arigo> yes
[15:57] <hpk> since a few minutes :-)
[15:57] <arigo> :-)
[16:05] <arigo> and already loosing my time on IRC :-)
[16:05] <arigo> pedronis, stakkars: actually I'm trying to rewrite normalize_exception at interp-level and see if we get nice big flow graphs.
[16:07] <pedronis> arigo: the problem is that doing wrt to old classes is overkill for the rpython flow graphs
[16:07] <pedronis> s/doing/doing the right thing
[16:07] <arigo> I just figured that out
[16:09] <arigo> maybe the space should have both primitive and "extended" operations:
[16:09] <arigo> space.istypeinstance/space.issubtype
[16:10] <arigo> space.isinstance/space.issubclass/space.isclass
[16:10] <arigo> the first group are real primitive space operations
[16:10] <arigo> the 2nd group by default falls back to the 1st group
[16:10] <arigo> but the stdobjspace overrides them to support old-style classes
[16:10] <arigo> in this way, only the stdobjspace has to worry about old-style classes
[16:11] <arigo> s/istypeinstance/instanceof, maybe
[16:12] <pedronis> I see, but the flow space and the annotator would still see four diffrent things, not that it is so bad
[16:12] <arigo> they would see a large mess of branches, yes
[16:13] <arigo> a smaller mess of branches for "raise XyzError" or "raise XyzError, value"
[16:13] <arigo> because in this case the w_type is a Constant
[16:13] <arigo> but it's not that bad -- at least we should try
[16:18] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "Leaving"
----- silence for 16 minutes ----- [16:34] <pedronis> arigo: how is it working
[16:35] <pedronis> as a doublecheck you may want to run translate_pypy.py targetpypy0 and look at pyframe.eval graph
----- silence for 16 minutes ----- [16:51] <arigo> pedronis: sorry, just had a small break
[17:04] <arigo> 'FlowObjSpace' object has no attribute 'w_tuple'
[17:04] <arigo> of course
[17:11] <pedronis> of course
[17:11] <pedronis> :)
[17:13] <arigo> let me first try with applevelinterp disabled
[17:16] <arigo> hum, sys.last_type/last_value are not normalized currently
[17:16] <arigo> that's a bug
[17:19] <arigo> ah
[17:19] <arigo> next problem is:
[17:19] <arigo> normalize_exception starts like this:
[17:19] <arigo> while space.is_true(space.isinstance(w_type, space.w_tuple)):
[17:19] <arigo> w_type = space.getitem(w_type, space.wrap(0))
[17:20] <arigo> that's not good for the flow space
[17:20] <arigo> because it's a potentially infinite loop
[17:22] <pedronis> yes, unless w_type is a constant
[17:22] <arigo> problem #0 is that constant-folding isinstance() doesn't seem to be implemented
[17:22] <arigo> so I get
[17:22] <arigo> Exception: found an operation that always raises TypeError: generated by a constant operation: getitem(<class exceptions.ValueError at 0x4023ab0c>, 0)
[17:24] <pedronis> isisnstance is defined in terms of type and issubtype
[17:25] <arigo> so 'type' is not constant-folded
[17:25] <stakkars> arigo: congratulations!
[17:25] <arigo> aAarg
[17:26] <arigo> of course constant-folding <class ValueError> gives <classobj>
[17:26] <arigo> and not <type>
[17:26] <stakkars> arigo: you know how to disable applevelinterp? uncomment one line after its definition
[17:26] <arigo> stakkars: just found it, yes, thanks
[17:27] <arigo> the comment about the line to uncomment was helpful :-)
[17:28] <arigo> AttributeError: 'FlowObjSpace' object has no attribute 'w_KeyboardInterrupt'
[17:29] <stakkars> yes, I know this one :-)
[17:30] <pedronis> yes type is not constant folded, if you put debug=1 at the top of flow space you get messages about what is missing
[17:30] <arigo> ok
[17:31] <arigo> fixed by folding it with a function type_or_something_similar() which returns 'type' instead of 'ClassType'
[17:33] <pedronis> quite a lot of stuff is not constant folded btw
[17:36] <pedronis> although we obvisouly don't want to constant fold setattr for example
[17:37] <arigo> stakkars: thanks for the congratulations btw
[17:37] <arigo> pedronis: indeed
[17:37] arre (ac@ratthing-b3fa.strakt.com) left irc: "using sirc version 2.211+KSIRC/1.3.11"
[17:37] <pedronis> the code is a bit fragile, if operator.setattr would be there we would get something we don't want
[17:38] <arigo> good point
[17:38] <arigo> we may get something we don't want with operation.setitem, btw
[17:39] idnar (mithy@idnar.user) left irc: "kbye"
[17:39] <pedronis> very much so :(
[17:42] <pedronis> we want to leave alone all the set* del* and inplace_* stuff
[17:42] <arigo> well
[17:42] <arigo> inplace_add between integers is fine
[17:43] <pedronis> yes, but then it get subtle
[17:43] <pedronis> we need to check types
[17:43] <arigo> ok ok
[17:43] <arigo> re exceptions:
[17:43] <arigo> is it ok if I add a space.abstract_isclass()
[17:44] <arigo> similar to abstract_isinstance() and abstract_issubclass() ?
[17:44] <pedronis> I expect, yes
[17:44] <arigo> or is this not what normalize_exception() should check for ?
[17:45] <arigo> IOW: do we want an exception mecanism that plays nicely with objects that just have the correct __class__ and __bases__ attributes ?
[17:46] <pedronis> it is not what CPython does but it should be ok
[17:46] <pedronis> but we probably want to have shortcut for the type case
[17:46] <arigo> the risk is to have "raise MyError(value)" crashing because there is a __bases__ attribute on MyError(value)
[17:47] <arigo> normalize_exception() would think it's a "raise Class" case and call it
[17:50] <pedronis> well that would happen if MyError is a metaclass
[17:50] <pedronis> or some strange code using a __bases__ attribute
[17:50] <arigo> yes, I'm thinking about the latter
[17:50] <stakkars> hmm, how can MyError(value) grow a__bases__ ?
[17:50] <arigo> class MyError:
[17:51] <arigo> def __init__(self, x):
[17:51] <arigo> self.x = x
[17:51] <arigo> self.__bases__ = x.parents
[17:51] <arigo> probably unwise to name a user attribute __bases__, but do we take the risk?
[17:51] <stakkars> ok, explicitly of course.
[17:52] <stakkars> I guess if we don*'t create infinite recursion or something, justlet it misbehave
[17:52] <arigo> it will try to call the MyError instance
[17:52] <pedronis> wich will die unless it also defines __call__
[17:52] <arigo> both cases lead to confusion
[17:53] <stakkars> people who want to use instances with __bases__ as exceptions should get what they expect: confusion
[17:54] <stakkars> well, don't we still restrict things to be instances of Exception subclasses?
[17:54] <arigo> no, never
[17:54] <arigo> :-)
[17:55] <stakkars> we did now, but didn't we want to?
[17:55] <stakkars> did not
[17:55] <arigo> you can raise instances of any old-style class in CPython
[17:55] <arigo> that's definitely used in many programs
[17:56] <arigo> but ok, I'll use abstract_isclass() and put an XXX
[17:56] <stakkars> so what normalize is supposed to do is to create some instance of something right?
[18:01] <arigo> fix w_type and/or w_value to make sure that the __class__ of w_value is exactly w_type.
----- silence for 17 minutes ----- [18:18] <stakkars> yup
[18:20] <arigo> ah, I'm getting nice graphs now
[18:21] <arigo> with only minimal head-banging infinite loop problems
[18:21] <stakkars> does your change (?) influence geninterp's strategy?
[18:21] <arigo> not sure
[18:22] <arigo> I moved normalize_exception() from the ObjSpace to the OperationError class, so there's a fix in geninterp to be done
[18:22] <arigo> but more than that, I didn't look yet
[18:22] <stakkars> but the way I call it after exceptclauses is still valid?
[18:22] <arigo> haven't looked yet
[18:23] <pedronis> I think the question is whether is still necesessary for generators do to their own normalization
[18:23] <stakkars> see my entry from 14.51
[18:23] <stakkars> hey, this would be nice to get rid of.
[18:24] <stakkars> I just tried to copy what CPython does. But if this is rendered as operations, evenbetter!
[18:25] <arigo> basically, we need to define what exactly the (last_exception) and (last_exc_value) entries in the graphs mean
[18:29] <pedronis> the is question is with implicitly raised exceptions, if the flow graph now normalizes the one going through a program raise
[18:30] <arigo> then (last_exc_value) is just a random object, often a string
[18:30] <arigo> and the flow graph will soon contains the necessary normalization operations.
[18:33] <pedronis> so last_exc_value would be an instance of last_exception
[18:33] <arigo> no, it would not
[18:33] <stakkars> ?
[18:33] <pedronis> ??
[18:35] <arigo> I just said in my opinion it can be a random object, often a string; how does this imply it would be an instance of last_exception?
[18:35] <stakkars> I think we meant after normalization
[18:35] <arigo> after normalization it is no longer last_exc_value, it is some v1234
[18:35] <stakkars> ok, ok !!
[18:35] <arigo> which was created by various operations etc.
[18:36] <arigo> and the codegen doesn't know that v1234 is meant to be a normalized exception value
[18:36] <pedronis> I'm meaning at runtime not in the graph
[18:37] <arigo> yes, at run-time the object going through the (last_exc_value) variable would be just a random object
[18:37] <pedronis> I don't understand
[18:38] <pedronis> you mean that the generators can pass whatever they want as last_exc_value?
[18:38] <arigo> last_exc_value is where the generator should catch and put whatever object the last operation said was the "exception value" object
[18:39] <arigo> I'm saying that the run-time library can pass whatever un-normalized object as the "exception value", often a string
[18:39] <pedronis> but then the annotator cannot do anything sensible with except clauses
[18:40] <pedronis> the annotator need to assume something about the normalization strategy and what is passed around by the generators at runtime
[18:42] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: Read error: 60 (Operation timed out)
[18:42] <arigo> you're right (I tried in a graph) but I don't see what I missed
[18:45] <pedronis> the annotator was assuming that what enters an except clause is normalized
[18:45] <pedronis> before the changes what leaved an explicit raise statement may have been unnormalized
[18:46] <pedronis> if I understand the change now it is normalized
[18:46] <pedronis> this is orthogonal to what is put into last_exc_value
[18:47] <pedronis> up to the fact that what concretely enters the except clause need to be normalized
[18:47] <arigo> argh argh argh
[18:47] <arigo> this is CPython:
[18:48] <arigo> {}[6]
[18:48] <arigo> KeyError: 6
[18:48] <arigo> {}[(6,)]
[18:48] <arigo> KeyError: 6
[18:48] <arigo> {}[None]
[18:48] <arigo> KeyError
[18:48] <stakkars> hehe
[18:48] <arigo> stupid thing is normalizing the error too much
[18:49] <arigo> what I've got now on my laptop is doing the same thing in the flow graph explicitely
[18:49] <arigo> for code like
[18:49] <arigo> try:
[18:49] <arigo> x[5]
[18:49] <arigo> except IndexError:
[18:49] <arigo> pass
[18:49] <arigo> the flow graph is large
[18:50] <stakkars> so in a sense you are inlining normalize_exception every time, I guess?
[18:50] <arigo> yes.
[18:50] <pedronis> >>> try:
[18:50] <pedronis> ... {}[(0,)]
[18:50] <pedronis> ... except KeyError, e:
[18:50] <pedronis> ... pass
[18:50] <pedronis> ...
[18:50] <pedronis> >>> e
[18:50] <pedronis> <exceptions.KeyError instance at 0x4022ab6c>
[18:50] <pedronis> my point is about e
[18:50] <arigo> yes, but that's easy now
[18:50] <stakkars> can we make a compromize, here, I fear we get huge code bloat
[18:50] <arigo> I mean on my machine
[18:51] <arigo> because the huge graph ends in explicit type checks
[18:51] <pedronis> maybe, we are talking past each other
[18:51] <arigo> so the annotator would figure out about e automatically, just because issubtype() is around as operations
[18:51] <pedronis> well right now it cheats
[18:52] <pedronis> but this is immaterial
[18:52] <arigo> ok wait a second
[18:52] <pedronis> because the types are for inside the except suite
[18:52] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
[18:52] <stakkars> I see that everything and all can be inlined, but we once said that inlining is not the goal right now.
[18:53] <stakkars> so there should be a interchangeable similar solution without inlining.
[18:53] <stakkars> otherwise I would have a hard time why we inline normalize, but not the rest of the whole library (boom)
[18:54] <pedronis> arigo: you are inlining it only for raise
[18:54] <arigo> svn switch http://codespeak.net/svn/pypy/branch/pypy-normalize-exception
[18:54] <pedronis> or also for the implicit stuff
[18:54] <arigo> look at what the translator gives you with this branch
[18:57] <arigo> it's just a rewrite of normalize_exception at interp-level, and I'm struggling to understand the consequences, so it's best if we're all talking about the same consequences.
[18:59] <pedronis> I see, this is about raise
[18:59] <pedronis> wich is what i thought
[18:59] <arigo> it is also about except
[18:59] <arigo> right now, they both call normalize_exception
[19:01] idnar (mithrandi@idnar.user) joined #pypy.
[19:02] ludal (~ludal@logilab.net2.nerim.net) left irc: "Download Gaim: http://gaim.sourceforge.net/";
[19:03] <pedronis> do tests pass?
[19:03] <arigo> no, it's still buggy
[19:03] <arigo> not to mention that try: f() except ValueError: crashes the flowobjspace
[19:04] <arigo> I wanted to show you the graph of
[19:04] <arigo> def fn(x):
[19:04] <arigo> try:
[19:04] <arigo> x[5]
[19:04] <arigo> except IndexError:
[19:04] <arigo> return -1
[19:06] <pedronis> well, .__class__ instead of type will not work for the annotator as it is
[19:07] <arigo> it's easily fixed
[19:07] <arigo> e.g. with a space.abstract_getclass() that is overridden by the flowobjspace
[19:07] <arigo> the problem I have is about the size of the graph
[19:14] <pedronis> I see
[19:14] <arigo> actually
[19:15] <pedronis> well, basically before the flow graph was mostly not normalizing on except
[19:15] <arigo> replacing getattr(__class__) with type() and another small hack makes the graph much smaller
[19:15] <arigo> (just checked in)
[19:16] <arigo> so the question is exactly how much normalization should we expect where
[19:16] <arigo> if you do a raise: and except:, you get the normalization twice
[19:16] <pedronis> well, the problem with the annotator was the non normalisation with the raises
[19:17] <arigo> yes, I suppose that the branch' approach is saner
[19:17] <pedronis> OTOH the amount of normalisation done with excepts was ok
[19:18] <stakkars> at least it is most similar to what CPython does.
[19:19] <arigo> stakkars: more or less
[19:19] <arigo> stakkars: I was thinking about going completely down this CPython-like road
[19:19] <arigo> stakkars: which would involve doing slightly different things at raise and at catch time...
[19:20] <arigo> but the amount of code generated can be problematic
[19:20] <arigo> typical example:
[19:20] <arigo> try:
[19:20] <arigo> mydict[key]
[19:20] <arigo> except KeyError:
[19:20] <arigo> stuff
[19:21] <arigo> this produces an incredible amount of checking things about 'key'
[19:21] <stakkars> I gues almost as much as is done in the normalize_exception, just less?
[19:22] <arigo> well even twice, because it is remotely possible that
[19:22] <pedronis> the annotator just assumes that normalisation has happened so most code will go away but only at that point
[19:22] <stakkars> I think it is just fine to have all this generated code, probably a good speed-up.
[19:23] <arigo> stakkars: no wait
[19:23] <stakkars> But then, I would try to capture all different cases and turn them into special functions to be called.
[19:23] <arigo> wait wait wait
[19:23] <stakkars> X-)
[19:23] <arigo> it's nonsense to have lots of code for the above example
[19:23] <arigo> in this example the expected code is: no code
[19:24] <stakkars> (looking again...) -- yes!
[19:24] <arigo> and even... wait...
[19:24] <stakkars> why no code? You must check for the KeyError, and you don't know what crap mydict is throwing
[19:24] <arigo> try:
[19:25] <arigo> mylist[index]
[19:25] <arigo> except IndexError:
[19:25] <arigo> pass
[19:25] <pedronis> stakkars: before you would just get the exception exit case going straight into stuff
[19:25] <arigo> now, suppose the following situation:
[19:25] <arigo> mylist is actually a dictionary
[19:25] <arigo> index is a special object
[19:25] <arigo> it's possible that index is convoluted enough
[19:26] <arigo> so that normalizing (KeyError, index) actually gives an IndexError instance
[19:26] <arigo> would you believe it?
[19:26] <arigo> the flow graph for the above snippet actually contains code that handles this possibility
[19:26] <pedronis> wich is overkill for RPython and most sane app-helpers too
[19:28] <pedronis> there no much way to cut code before the annotator, unless we cheat again
[19:28] <arigo> we want the above snippet to eventually compile to code that indexes the list, or ignores out-of-bound indexes -- nothing more!
[19:28] <stakkars> yeah, it seems to be useful for annotating parts of full Python.
[19:29] <arigo> pedronis: any idea how much can be removed after the annotator?
[19:29] <pedronis> a lot, depends on subtle things
[19:30] <pedronis> it would enter the except code assuming IndexError, object that is an instance of IndexError
[19:30] <arigo> first unresolved question:
[19:30] <pedronis> the problem is that before the change
[19:30] <arigo> I imagined that the annotator would no longer assume anything about last_exc_value
[19:31] <pedronis> then the code will stay
[19:31] <pedronis> it has no reason not to
[19:32] <pedronis> it will remove some stuff about last_exception being a type and that's it
[19:32] <pedronis> but as was saying, in this case before we were doing some constant folding also in exception_match
[19:34] <arigo> there is a way to make this code go away
[19:34] <arigo> the IndexError instance is never used
[19:35] <arigo> if you teach transform.py that simple_call(<exception subclass>, ...) has no side-effects
[19:35] <arigo> and with some more efforts here and there, it all goes away
[19:35] <pedronis> well, but a lof will stay if you use it
[19:36] <arigo> ok what I am saying is that we have basically two options, from this point:
[19:36] <arigo> (1) hack around special cases for exceptions and normalizations all around the place
[19:37] <pedronis> one issue is also that is an open question whether expanding the internal semantics for raise and catch is good idea for the point of view of the different backends
[19:37] <pedronis> with may want to have their own control
[19:38] <arigo> (2) have all the logic in the flow graphs with a simple, non-Python-specific definition of what exception matching means and nothing defined on what can appear in the auxiliarly (last_exc_value)
[19:39] <arigo> to answer your question, I don't think the back-ends should care about this, it's pretty much an internal question for R-Python
[19:39] <stakkars> if (2) takes 10 times longer than (1) to implement, I'd go for now for the thing that yields some executable, first
[19:39] <arigo> (2) is basically done in the branch. (1) is a lot of hacks...
[19:40] <pedronis> well do the tests pass, is not until that
[19:40] <arigo> but (2) puts more burden on optimization
[19:40] <pedronis> is not done
[19:40] <arigo> "basically done" :-)
[19:40] <arigo> I mean it's not finished but just an experimentation...
[19:40] <pedronis> I don't think we want the annotator chew on a lot of code
[19:42] <arigo> in option (1) I wonder about the run-time library, which has to ensure it produces normalized last_exc_value all the time
[19:43] <arigo> similar to geninterplevel which has to call normalize_exception() whenever it catches an OperationError
[19:45] <arigo> it's true that the sanest option (3) would be not to have the notion of un-normalized exceptions at all
[19:45] <stakkars> that would move the issue into the context of raise
[19:45] <arigo> yes, it would localize the mess in the implementation of the raise statement.
[19:46] <stakkars> and would be slower, for situations where the exception is ignored.
[19:46] <arigo> slower than (2) but right now (1) is always normalizing anyway.
[19:47] <stakkars> it is the gap between cheap raising versus cheap capturing - cannot have both
[19:47] <pedronis> yes, we are already always normalizing
[19:47] <arigo> maybe it's a case where we should just drop the whole laziness optimization of CPython...
[19:48] <pedronis> at the from the flow space point view, yes
[19:48] <pedronis> at least
[19:48] <stakkars> well,wemightspecial-case a few common patterns for RPython, can't we?
[19:49] <stakkars> like StopIteration, KeyError or IndexError for common things like iterators, lists, dicts, which we implement - I'm happy if these are as fast as possible and don't care about the rest.
[19:50] <arigo> stakkars: do you mean, in other words:
[19:50] <arigo> for things like
[19:50] <arigo> try:
[19:50] <arigo> mylist[index]
[19:50] <arigo> except IndexError:
[19:50] <arigo> pass
[19:50] <arigo> making sure that no IndexError instance is created
[19:51] <stakkars> if mylist ir proven to be a real list, yes
[19:51] <arigo> this might be easy actually, if the (last_exc_value) in the flow graph is never used and completely removed, then the code generator can insert a simpler indexing operation...
[19:52] <arigo> seeing that the "exitswitch: (last_exception)" branch doesn't have a (last_exc_value) input arg any more.
[19:53] <arigo> maybe it makes more sense than hoping a graph of 11 blocks full of branches can be completely optimised away :-)
[19:53] <stakkars> I would go even further for implicit exceptions which are used in our interpreter implementation:
[19:54] <stakkars> I would add to the RPython definition that exceptions should be raised in a way that doesn't need normalization, maybe
[19:54] <arigo> stakkars: we already went there...
[19:54] <stakkars> with no success?
[19:54] <arigo> it used to be specified by R-Python
[19:54] <arigo> but too many places needed strange "raise" patterns
[19:55] <pedronis> we have places that use the 3 arg raise
[19:55] <pedronis> we could still require that the second argument is an instance of the first
[19:55] <stakkars> that's ok, I suggested yesterday to do completely different branches,depending on the arity of raise
[19:56] <arigo> pedronis: this requirement would require a lot of rewriting :-(
[19:56] <stakkars> just make it three different operations.
[19:56] <arigo> pedronis: also, the raise Class vs raise Class(args...) difference is difficult
[19:56] <pedronis> I know
[19:56] <arigo> but that's maybe not the point
[19:56] <pedronis> and I had to do some of that rewriting
[19:57] <pedronis> because of the raise non-normalizing issue
[19:57] <arigo> if the flow graphs contain a full handling of all cases of 'raise' statements, it's probably still fine
[20:00] <stakkars> did we use things like "raise, c, v, t" with allargs being variables?
[20:00] <pedronis> I don't think so
[20:00] <stakkars> (skimming all raise statements of the project...)
[20:01] <pedronis> but figuring out raise C(...) is harded
[20:01] <pedronis> because C(...) itself can get surrounded by exception handling code because it is a call
[20:02] <stakkars> the question is: is the C() always encountered literally (causing a call_function entry), or do we pass things around?
[20:02] <pedronis> I don't recal places where is not literal
[20:03] <stakkars> most of the hundreds of places I inspected right now, we have the two basic things:
[20:03] <stakkars> raise const, value
[20:03] <stakkars> raise const(value)
[20:04] <arigo> we already did all this analysis
[20:05] <stakkars> and put the results into which web page? :-)
[20:05] <arigo> all these special cases and assumptions are basically what's now in FlowObjSpace.exception_match
[20:05] <stakkars> yes.
[20:05] <arigo> this, in turn, used to be in specialcases.py
[20:05] <arigo> and it used to be simpler
[20:05] <arigo> but we kept discovering new strange cases
[20:05] <arigo> it makes no sense to start all over again, does it?
[20:06] <stakkars> I don't know whether it is easier to avoid the strange cases.
[20:06] <pedronis> yes, you make it throw exceptions
[20:06] <pedronis> and fix the code
[20:06] <stakkars> exactly.
[20:07] Action: arigo lost
[20:07] <pedronis> the problem with flow space is that in a lot of cases it produces bogus results
[20:07] <pedronis> instead of raising exception about what it cannot handle properly
[20:10] <pedronis> the options are: pursue the branch and inline all the normalization code and makes the tests pass again
[20:10] <pedronis> do that partially fully normalizing on raises and special casing the execpt
[20:11] <pedronis> or take the old normalize_exception in the flow space and make it raise exception for things is not handling properly and
[20:11] <pedronis> change the code that trigger that
[20:12] <arigo> I figured out what is probably the fastest path:
[20:12] <arigo> move a line in pyframe.py
[20:12] <arigo> so that normalize_exception() is not called at all during flow analysis
[20:12] <arigo> (checked in the branch)
[20:12] <arigo> with the following results:
[20:12] <arigo> the exceptions caught in the flow graph are assumed to be normalized always
[20:13] <arigo> the raise statements produce explicit normalizing operations in the graph
[20:13] <arigo> which both seem to give sensible graphs.
[20:13] <pedronis> yes, that's a form option two
[20:14] <stakkars> general comment: I think if the way we implement a translatable interpreter leads us to make exception handling even more complex than CPython's, we might ask ourselves what we are trying to achieve.
[20:14] <arigo> stakkars: absolutely -- that's why I like what I just checked in :-)
[20:14] <stakkars> (wanted to say that before arigo started, so it might be neglectible, now)
[20:16] <pedronis> arigo: yes
[20:16] <pedronis> test_annrpython passes
[20:16] <arigo> there is a failure in interpreter/test/test_exceptcomp which puzzles me
[20:17] <stakkars> should I check out the branch, or are you about tomerge?
[20:17] <pedronis> arigo: I see it
[20:18] <arigo> the branch wasn't originally meant to be merged back
[20:19] <arigo> it was a quick way to show you the code... but we could take specific files back to the trunk
[20:19] <arigo> pedronis: I don't get it, it works fine if you paste the code in py.py
[20:20] <pedronis> some strange interecaction with the special AssertionError of the testing framework?
[20:21] <arigo> argh
[20:22] <arigo> quite possibly
[20:23] <stakkars> hate. Let's have a hook that restores things to a sane system while flowing.
[20:23] <arigo> stakkars: that's not related to flowing.
[20:24] <arigo> pedronis: the test passes if you s/AssertionError/IndexError
[20:24] <pedronis> so, yes, it is specific to the tweaked AssertionError :(
[20:25] <arigo> argh!
[20:25] <arigo> it's because this new AssertionError has __module__ == '__builtin__'
[20:25] <arigo> so we get a TypeError: raising built-in objects can be ambiguous, use 'raise type, value' instead
[20:26] <pedronis> instead of exceptions.
[20:27] <stakkars> can't we have a tweaked AssertionError that has __module__ == __builtin__, but simply is different from the original?
[20:27] <stakkars> sorry, __module__ == exception of course
[20:27] <pedronis> arigo: that should be easy to fix
[20:28] <arigo> yes
[20:28] Action: pedronis needs to go buy stuff, see you later
[20:29] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050325]"
[20:44] <arigo> stakkars: I think I'll merge the branch to the trunk after all
[20:44] <arigo> stakkars: soon ready, but I must go to dinner now
[20:44] <arigo> see you later
[20:44] <stakkars> ok
[20:44] <stakkars> do I need to change something, then?
[20:44] bbiow (bbiow@82.145.232.36) joined #pypy.
[20:44] <stakkars> or disable geninterp until I adapted
[20:59] bbiow (bbiow@82.145.232.36) left irc: "Leaving"
[21:12] pedronis (~Samuele_P@c-158b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 48 minutes ----- [22:00] <arigo> hi back
[22:08] <arigo> sorry for the slightly "heated" discussion, don't know why it got like this.
[22:09] <stakkars> ? should I have feltmore heat? I liked it. :)
[22:12] <arigo> well I feel like I crashed with my big feet into a discussion where I didn't know what was really the problem and the consequences, specially about the annotator, and just imposed a solution because I found it cleaner...
[22:13] <arigo> I guess I'd like Samuele to review a bit the branch and tell if it's a reasonable solution.
[22:14] <arigo> btw the branch has applevelinterp disabled; I guess that geninterp only needs to fix whose normalize_exception() method it calls (the operr instead of the space).
[22:14] <stakkars> fine
[22:15] <stakkars> maybe we need some config flags in a central file at some time.
[22:15] <stakkars> Things like geninterp have a huge impact when they break if enabled.
[22:15] <pedronis> arigo: np, the fact is that there is lot still to do before annotating all of PyPy, and didn't feel that the complexity of inlining norm exceptions in the except cases is worth it right now
[22:16] <pedronis> OTOH it is true that the way the annotator handle excepts is a bit fragile
[22:17] <pedronis> and otoh the unnormalized stuff coming out of raises was a problem
[22:17] <arigo> :-)
[22:18] <arigo> (off-topic: www.oldgames.dk has tons of old games rewritten in Javascript :-)))
[22:19] <pedronis> the fact is that the annotator marks the exception values at exception exitcase point ->
[22:20] <pedronis> if this break, we probably need to specialize more exception_match or use the exc_handler flag that now is unused
[22:21] <pedronis> because they are nearer to the point of consumption of the exception values
[22:22] <pedronis> but is more special-casing
[22:25] <pedronis> The fact is that our exception catching is partly in the model of the graph (link.exitcase kind) and partly inlined from what the interp does
[22:31] <pedronis> arigo: the onyl failures I see on the branch are test flow objspace itself and geninterp
[22:33] <pedronis> the flow objspace tests are checking the shape of graph with raise in them
[22:37] <arigo> yes, I see it
[22:39] <arigo> I don't know what the annotator does with flagging exception values
[22:40] <arigo> that's also why I felt a bit wrong here, I should have digged a bit more into that
[22:40] <pedronis> I'm trying translate_pypy.py targetpypy0
[22:40] <pedronis> and I get a UnwrapException
[22:44] <pedronis> arigo: it's something trying to interpclass_w a traceback
[22:44] <pedronis> which is a variable now
[22:44] <pedronis> with the old code special-cased code tb was a constant
[22:45] <pedronis> None
[22:47] <arigo> let me try
[22:48] <pedronis> arigo: I think the the branch about tb not being None
[22:48] <pedronis> should be used only with full_exceptions
[22:48] <arigo> this would ignore the 3rd argument of 'raise'...
[22:48] <pedronis> yes
[22:49] <arigo> which is probably just what we want indeed :-)
[22:49] <pedronis> yep
[22:51] <arigo> can I check this in?
[22:53] <arigo> cannot follow call(SomeInstance(classdef=OperationError), Arguments([]))
[22:56] <pedronis> yes
[22:57] <pedronis> that cannot follow is because type does not do the right thing with SomeInstance
[22:57] <pedronis> it's easy to fix
[22:57] <arigo> I see
[22:57] <arigo> actually the issubtype operation is not known to the annotator at all, right?
[22:57] <pedronis> no, issubtype is known
[22:58] <pedronis> in fact much of exception handling annotation depends on that
[22:58] <arigo> not the issubclass() built-in
[22:58] <arigo> ah
[22:59] <pedronis> because exception_match expends to is and isubtype in the graph
[22:59] <pedronis> s/expends/expands
[22:59] <arigo> ah, it's a binary op -- I looked in unary
[22:59] <arigo> we need to extend it to annotate raise IndexError(x) properly
[23:00] <pedronis> I have a fix for type(.) and space.type
[23:01] <arigo> what can type(SomeInstance) return?
[23:01] <arigo> it could be a subclass
[23:02] <pedronis> umph, yes
[23:02] <pedronis> I think we had that discussion in Leysin and punted
[23:02] <arigo> but issubtype() can be made more subtle
[23:03] <arigo> if the 1st argument is_type_of SomeInstance, we can often know the answer exactly
[23:04] <pedronis> yes
[23:04] <arigo> oh
[23:05] <arigo> issubtype isn't called somehow
[23:05] <pedronis> I'm looking at what is going on
[23:05] <arigo> aAargh
[23:05] <pedronis> because my brute force fix is not working either
[23:05] <arigo> issubclass(x, type) won't work
[23:06] <arigo> because immutablevalue(type) returns SomeBuiltin(builtin_type)
[23:06] <arigo> grumble
[23:07] <pedronis> and also because the exception will be old style
[23:07] <arigo> hum right
[23:07] <arigo> let me make issubtype a unary method first
[23:08] Action: hpk sidenotices that at some point a larger more theoretic picture of annotation would be nice
[23:09] Action: arigo hits hpk with a practical stick
[23:09] <hpk> arigo: theory theory theory (i hear your words :-)
[23:09] <pedronis> only when CPython exceptions are new-style
[23:10] <pedronis> it's one of the painful charateristic of Python right now wrt PyPy
[23:15] <arigo> pedronis: can SomeXxx.is_type_of be a list of more than one s_instance ?
[23:16] <pedronis> yes but
[23:16] <pedronis> the content are variables not SomeObjects
[23:16] <arigo> ah
[23:20] <stakkars> about togo: was there a merge checkin,already?
[23:21] <arigo> pedronis: are you still hacking on issubclass & friends or can I check it? seems to do the right thing on an example
[23:21] <pedronis> you can check in
[23:23] <arigo> does it make sense to merge back the branch now?
[23:23] <pedronis> let me check how the targets look like
[23:25] <pedronis> arigo: targetpypy0 dies
[23:25] <arigo> yes, I just figured out why:
[23:26] <arigo> raise OperationError, operr, tb
[23:26] <arigo> "maybe operr is None?" thinks the annotator
[23:26] <arigo> in this case it tries to call OperationError() with no arg -> crash
[23:27] <pedronis> yes
[23:27] <arigo> we need some kind of flag "cannot be None"
[23:27] <arigo> maybe it might be more useful to have a flag "this SomeInstance is really of this class and not of any subclass"
[23:28] <arigo> "and not None either"
[23:28] <pedronis> can be None or not is also an open issue
[23:28] <arigo> yes
[23:28] <arigo> maybe it's useful information to have also at other places
[23:29] <pedronis> yes
[23:29] <pedronis> for example it would remove some is None branches in some places
[23:29] <arigo> ok
[23:30] <arigo> mind if we merge the branch anyway before someone else modifies the trunk?
[23:30] <pedronis> ok
[23:30] <arigo> or would you prefer to keep translate_pypy in roughly better shape?
[23:30] <pedronis> well, that's the question
[23:31] <stakkars> bye,guys
[23:31] <arigo> good night
[23:31] <pedronis> bye stakkars
[23:31] <stakkars> don't forget to sleep (o)
[23:31] <arigo> :-)
[23:31] <pedronis> :)
[23:32] stakkars (~tismer@82.144.60.19) left irc: "I"
[23:32] <arigo> I don't mind some early crashing translate_pypy pointing at the next problem, but you're the one working on it most of the time :-)
[23:33] <pedronis> well, I think hadding a is not None flag to SomeInstance is not hard
[23:34] <pedronis> I don't think there are places were SomeInstance(...) means can be None
[23:34] <pedronis> where
[23:34] <pedronis> so it would be set when we unify with None
[23:34] <arigo> makes sense
[23:34] <arigo> however I'm done for tonight, need more sleep
[23:35] <arigo> go ahead and merge when you like (don't forget to time.sleep())
[23:35] <pedronis> :)
[23:35] <arigo> :-) bye
[23:36] <pedronis> bye
[23:36] arigo (~arigo@stups.cs.uni-duesseldorf.de) left irc: "[x]chat"
[00:00] --- Thu Apr 7 2005