[00:29] SamB (naesten@r226120.res.Lehigh.EDU) left irc: Remote closed the connection
----- silence for 1 hr and 5 minutes ----- [01:34] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041107]"
----- silence for 28 minutes ----- [02:02] Continuity (kittish@host81-153-48-22.range81-153.btcentralplus.com) left irc: Remote closed the connection
[02:10] _hannes (psforsav@i528C1B01.versanet.de) joined #pypy.
----- silence for 53 minutes ----- [03:03] _hannes (psforsav@i528C1B01.versanet.de) left irc: "utz utz utz"
----- silence for 2 hr and 42 minutes ----- [05:45] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: Read error: 113 (No route to host)
----- silence for 5 hr and 41 minutes ----- [11:26] arigo (~arigo@d213-103-137-124.cust.tele2.ch) joined #pypy.
----- silence for 1 hr and 2 minutes ----- [12:28] <hpk> arigo: morning
[12:28] <hpk> yesterday i experimentally used your hack/misc/collect class
[12:28] <hpk> it's nice
[12:29] <hpk> i was wondering if it shouldn't inherit from the list type
[12:29] <arigo> morning
[12:29] <hpk> to satisfy places where one checks for isinstance(x, (tuple, list)) ...
[12:30] <arigo> it would be nice, but it's not safe
[12:30] <hpk> in which sense?
[12:30] <arigo> otherwise, C code will try to read from the list without going through my methods
[12:31] <arigo> but maybe we could force __class__ to list :-)
[12:31] <hpk> are there places in the core that do this?
[12:31] <hpk> i know they exist for dicts but for lists?
[12:31] <arigo> of course
[12:31] <arigo> all C code using lists would skip my methods
[12:32] <arigo> e.g. if you say list(x)
[12:32] <arigo> if x is a subtype of list, no user-defined methods will be used
[12:32] <hpk> bah
[12:34] <hpk> hum, are you sure?
[12:34] <arigo> quite
[12:34] <arigo> yes.
[12:34] <hpk> me too:-9
[12:35] <hpk> although:
[12:35] <hpk> class X(list, collect): pass
[12:36] <hpk> list(X(enumerate([1,2,3])))
[12:36] <hpk> works
[12:36] <hpk> with isinstance(X(...), list) is True
[12:37] <arigo> well but it's calling list.__init__ too, so it's not lazy
[12:38] <arigo> (in 'python -i collect.py' you have objects c and d which print in red the items as they are actually read)
[12:39] <hpk> i don't get special prints
[12:40] <arigo> python -i collect.py
[12:40] <arigo> >>> c
[12:40] <arigo> 0
[12:40] <arigo> 2
[12:40] <arigo> 4
[12:40] <arigo> collect([0, 2, 4...)
[12:40] <arigo> >>>
[12:40] <arigo> with 0, 2 and 4 in red
[12:40] <hpk> ok
[12:41] <hpk> i was testing with def f(): for x in range(1000): yield x
[12:41] <hpk> c=collect(f())
[12:41] <arigo> ok
[12:41] <hpk> but the print is just in the __main__ code i see
[12:42] <arigo> yes.
[12:43] <hpk> i am getting close to merging the py-collect branch, btw
[12:43] <hpk> i was intermediately using the collect class but backed it out for now
[12:44] <arigo> :-)
[12:45] <hpk> actually i wouldn't mind if you review the new structure a bit
[12:45] <hpk> mainly the collect classes now don't use extpy anymore
[12:46] <arigo> I'm swimming through different issues right now...
[12:46] <hpk> and collectors and items uniformly have a "run()" method
[12:46] <hpk> which the driver calls
[12:46] <arigo> (btw:
[12:46] <arigo> class X(object):
[12:46] <arigo> __class__ = list
[12:46] <arigo> seems to do the trick.
[12:46] <arigo> it's not a list as far as CPython is concerned
[12:46] <hpk> ups
[12:46] <arigo> but isinstance(x, list) returns True
[12:46] <hpk> :-)
[12:46] <arigo> )
[12:47] <hpk> i think the collect class could go into py.builtin.lazylist ...
[12:47] <hpk> ... if it grew a couple of tests :-)
[12:48] <hpk> or do you think it's too tricky to rely on it?
[12:48] <arigo> no, that was the idea
[12:48] <arigo> why builtin?
[12:49] <arigo> oh, I see py.builtin.enumerate, makes sense
[12:49] <hpk> the idea is that you can do "from py.builtin import *" at some point
[12:49] <arigo> ah
[12:49] <hpk> but i am not sure about it exactly
[12:50] <arigo> note also the "future design goal" which is important to implement first
[12:50] <arigo> I also want to play with a version of CPython where the generators return a collect() :-)
[12:51] <hpk> :-)
[12:51] <hpk> it all does make sense i think
[12:51] <hpk> it was just a three-line change at one place to use collect() instead of a list
[12:52] <arigo> :-)
[12:52] <hpk> and regain the lazyness without having to bother the rest of the program with lazyness/iteration
[12:52] <arigo> same about dict.keys() & co, if I can protect the user against dict change
[12:52] <arigo> and range(), of course
[12:52] <hpk> i think it's a fine idea
[12:53] <arigo> file.readlines()
[12:53] <hpk> yes
[12:53] <arigo> and then mention it on python-dev :-)
[12:53] <hpk> the py lib could start to return lazylists/collect's instead of plain lists
[12:53] <hpk> therefore i asked for providing sufficient list-isinstance-likeness
[12:54] <arigo> I see
[12:54] <hpk> it allows to make this a drop-in replacement
[12:56] <arigo> we could have a magic lazylist class which pretends to be a list, but does nothing otherwise
[12:56] <arigo> whose purpose is to be subclassed with custom __getitem__() & co
[12:56] <arigo> i.e. lazylist would be a list pseudo-subclass which honors user overrides
[13:01] <hpk> maybe
[13:02] <arigo> anyway, any place doing isinstance(x, (list, tuple)) is considered broken :-)
[13:02] <hpk> mostly but not completely IMO
----- silence for 27 minutes ----- [13:29] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy.
----- silence for 34 minutes ----- [14:03] _hannes (rnqqftav@i528C1B01.versanet.de) joined #pypy.
[14:06] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 1 hr and 1 minute ----- [15:07] <pedronis> hi
[15:17] <hpk> hi
[15:21] <arigo> hi
[15:21] <pedronis> I noticed again the fact
[15:21] <pedronis> that in our flow graph
[15:21] <pedronis> the except suites
[15:22] <pedronis> at the least the first part is duplicated
[15:22] <arigo> do you have a specific test showing this=
[15:22] <arigo> ?
[15:22] <pedronis> look at the graph of
[15:22] <pedronis> try:
[15:22] <pedronis> g()
[15:23] <pedronis> except Exception:
[15:23] <pedronis> h()
[15:23] <pedronis> in some def f()
[15:23] <pedronis> one solution I tried is to add to the joinpoints
[15:24] <pedronis> which works
[15:24] <arigo> I see
[15:24] <arigo> I tried without joinpoints
[15:24] <arigo> at all
[15:25] <arigo> (I meant with joinpoints everywhere, rather)
[15:25] <arigo> beside the mess to fix the flow/tests,
[15:25] <arigo> we have a problem in specialcase.py
[15:25] <arigo> which looks at the previous operation sometimes
[15:25] <arigo> so if it's in another block, it doesn't find it
[15:27] Last message repeated 1 time(s).
[15:27] <pedronis> with joinpoints everywhere you get a block per operation?
[15:27] <arigo> yes
[15:28] <arigo> I'm going to try something else
[15:28] <arigo> which is to create a joinpoint just before any operation
[15:28] <arigo> you also get a block per operation,
[15:28] <arigo> but it's ok for specialcase.py
[15:29] <pedronis> well, could you not add simply a joinpoint
[15:29] <arigo> if we don't start a new empty block before a new operation is actually seen
[15:29] <pedronis> at the beginning of eggblocks
[15:29] <arigo> eggblocks don't start at any opcode position
[15:35] <arigo> oh, you mean add a joinpoint just after the opcode that created EggBlocks
[15:35] <arigo> I have a different goal in mind
[15:36] <arigo> def jump_target_specialization(x):
[15:36] <arigo> if x:
[15:36] <arigo> n = 5
[15:36] <arigo> else:
[15:36] <arigo> n = 6
[15:36] <arigo> return n*2
[15:36] <arigo> I'd like this flow graph to contain no 'mul' operation any more
[15:39] <pedronis> is it really a task for the flow space?
[15:39] <arigo> yes, in some cases it must be done by the space
[15:40] <arigo> what I have in mind is that it would be nice if the space could process
[15:40] <arigo> the output of geninterplevel.py, with no special SpecTag, and without crashing on unbound locals
[15:41] <pedronis> I see so above you don't want a joinpoint
[15:41] <pedronis> unless some operation with variables
[15:41] <arigo> yes exactly
[15:42] <arigo> ah yes:
[15:42] <arigo> I remember something else that went very wrong with joinpoints-at-every-bytecode
[15:42] <arigo> in exception handlers we have code that is similar to
[15:43] <arigo> if f() or g():
[15:43] <arigo> in such code there is normally a join point between the "or" and the "if"
[15:43] <arigo> if f() is false, this is wasteful
[15:46] <arigo> (I mean the control flow for the case where f() is false, is as strange as in CPython: two conditional tests on the same answer)
[15:46] <arigo> hum, I'm talking non-sense here
[15:47] <arigo> but I do remember a case with exception handlers which passed constant False and True values around, and checked them immediately...
[15:53] <pedronis> so we want both more and less joinpoints
[15:53] <arigo> guess so
[15:54] <pedronis> could not make the join new block creation lazy
[15:54] <arigo> that's why I'm wondering if we couldn't derive the joinpoint positions dynamically
[15:54] <arigo> yes, I'm trying to (it prompted this morning's cleanup)
[15:57] <pedronis> of course one block per operation has its own overhead
[15:58] <arigo> not too much, because we simplify the graph straight ahead in practice
[15:58] <arigo> but the flowcontext will make frame snapshots more often, definitely
[15:59] <pedronis> yes
[15:59] <pedronis> what I was thinking is that you could still use the labels as hints
[16:01] <pedronis> basically instead of creating a block eagerly when reaching a label
[16:01] <pedronis> you just mark that you traversed a canditate join point
[16:02] <arigo> just did that :-)
[16:04] <pedronis> you mean this approach
[16:05] <arigo> yes I'm trying this approach, and just wrote the bit "mark candidate join point"
[16:06] <arigo> but without using the labels at first
[16:06] <arigo> so it's going to create a lot of candidate join points, but never mind for now
[16:14] <arigo> too bad I can't paste a flow graph image here
[16:14] <arigo> there is an empty block pointing back to itself
[16:17] <pedronis> it's for the example above, jump_target_spec
[16:17] <arigo> no, for more trivial examples
[16:17] <arigo> a minor bug, to be sure
[16:20] <arigo> ok, now I get a more-or-less reasonable graph for try: f() except E: g()
[16:21] <arigo> there is only one simple_call(g)
[16:21] Eventh (evenwiik@v201a.studby.ntnu.no) joined #pypy.
[16:21] <arigo> all "leaf" EggBlocks are empty, though
[16:22] <arigo> the jump_target_spec test passes too
[16:23] <arigo> flowcontext.py looks relatively clean now
[16:23] <arigo> trying to make EggBlock creation more lazy...
[16:32] <arigo> hum, that's more effort than it's worth
[16:35] <pedronis> but that means you cannot reabsorb conditionals
[16:36] <arigo> ?
[16:36] <pedronis> if you had some conditonal in the n*2 part of your example
[16:37] <arigo> e.g.?
[16:38] <pedronis> no sorry, EggBlocks are created only if the condtion was a variable
[16:38] <arigo> yes
[16:46] <arigo> what is nice now is that it doesn't depend any more on code.getjoinpoints()
[16:52] <pedronis> well, they could still be used as a hint
[16:53] <arigo> I'm not sure how
[16:54] <pedronis> well, the question is whether speed of anlysis has worsened so that we have to care
[16:54] <arigo> translate_pypy1.py takes a real long time now, but I don't know if it's related to my change (sounds suspicious)
[16:59] <pedronis> it seems is analysing much more of PyPy?
[16:59] <arigo> no, it's asking for the flow graph of the same functions over and over
[16:59] <pedronis> fishy
[17:00] <arigo> it's the fault of revision 9657 (dynamic merge points)
[17:03] <arigo> maybe I'm wrong, at any rate it's finding much more functions that before
[17:03] <pedronis> yes
[17:03] <pedronis> what I said
[17:03] <pedronis> I get a much larger graph
[17:07] <arigo> yes
[17:10] <arigo> it's not the real problem here, but it helps make things worse:
[17:10] <arigo> getattr((W_IntObject), '__mm_mul')
[17:10] <arigo> returns a very unspecific SomePBC with all possible __mm_mul methods
[17:11] <arigo> before my change, only W_IntObject and W_NoneObject were ever seen
[17:11] <arigo> now for some reason, more W_XxxObject classes are seen -> explosion
[17:12] <pedronis> well, __mm_mul belongs to W_Root
[17:13] <arigo> yes
[17:14] <arigo> I wonder if it's linked to the getattr-no-rev-reflowing
[17:14] <arigo> which wouldn't do its job properly
[17:15] <arigo> because I'm wrong: W_IntObject, W_FloatObject, W_LongObject are all seen, even in previous versions
[17:15] <arigo> but previously, pygame said that getattr((W_IntObject), '__mm_mul') was a SomePBC of two functions
[17:16] <arigo> I messed up something in classdef.py
[17:18] <arigo> discovering new subclasses calls add_source_for_attribute(), which can change the value of attributes... I forgot to reflow
[17:19] <pedronis> yes
[17:21] <arigo> uh, locate_attribute()'s last return statement is suspitious
[17:22] <arigo> ah no, sorry
[17:24] <pedronis> which means we reflow
[17:26] <arigo> in add_source_for_attribute() ?
[17:27] <pedronis> no
[17:27] <arigo> no?
[17:29] <pedronis> so we need to call generalize_attr
[17:30] <arigo> I copy-pasted the two lines doing the reflow into add_source_for_attribute(), is that wrong?
[17:30] <pedronis> no
[17:31] <pedronis> but classdef really need a cleanup
[17:31] <pedronis> some stuff is done multiple time
[17:31] <pedronis> and some other happen just as a very inderict side effect some something else
[17:38] <pedronis> for example, I don't understand why there's no break in generalize_attr
[17:39] bzimmer (~bzimmer@c-24-13-11-91.client.comcast.net) joined #pypy.
[17:39] <arigo> that is a very good question
[17:40] <pedronis> at a very minimum
[17:40] <pedronis> we reflow twice if there just one class involved
[17:41] <pedronis> in fact in my changes
[17:41] <pedronis> I put an assert and code there
[17:41] <pedronis> such that _generalize_attr was called only on one class
[17:41] <pedronis> and nothing broke
[17:41] <arigo> the missing 'break' is a bug, I guess _generalize_attr() used to always raise BlockedInference
[17:42] <pedronis> ah ok
[17:42] <pedronis> it will avoid some reflowing
[17:43] <arigo> locate_attribute() could call _generalize_attr() instead of generalize_attr()
[17:52] <pedronis> yes
[17:53] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: "Leaving"
[17:54] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy.
[18:03] <arigo> ah, I see
[18:04] <arigo> W_IntObject().__mm_mul()
[18:04] <arigo> appears to call all possible methods, but each with a precise s_self
[18:05] <arigo> we should just pretend we're not calling the ones with an incompatible s_self
[18:08] stakkars (lupvqz@i528C1B01.versanet.de) joined #pypy.
[18:18] _hannes (rnqqftav@i528C1B01.versanet.de) left irc: "utz utz utz"
[18:19] <stakkars> hi
[18:20] <pedronis> arigo: you want SomeInstance.getattr to be more precise?
[18:22] <arigo> I'm trying, yes
[18:22] <arigo> but I'm running into an unrelated problem
[18:23] bzimmer (~bzimmer@c-24-13-11-91.client.comcast.net) left irc:
[18:23] <arigo> see the test I just checked in
[18:24] <arigo> uh...
[18:24] <arigo> there is an undeterministic assertion error
[18:24] <arigo> if I just do:
[18:24] <arigo> t = Translator(snippet.methodcall_is_precise)
[18:25] <arigo> a = t.annotate([])
[18:25] <arigo> I usually tigger an assertion in annrpython.py:389
[18:26] <pedronis> you simplifying
[18:26] <pedronis> you need
[18:26] <arigo> doesn't help
[18:30] <arigo> ah I see
[18:30] <arigo> I have to simplify *all* graphs, not just the one I loaded first
[18:30] <pedronis> yes
[18:31] <arigo> thanks
[18:31] <pedronis> I need to add a flag
[18:31] <pedronis> to graph
[18:31] <pedronis> probably
[18:31] <pedronis> that new part of exception handling annotation
[18:32] <pedronis> works only with simplified graphs
[18:32] <arigo> I see
[18:32] <pedronis> I could make it work
[18:32] <pedronis> for the general case
[18:32] <pedronis> but the code would be messier
[18:32] <arigo> ok, now hacking the PBCs in SomeInstance.getattr() makes the new test pass
[18:32] <arigo> yes I remember having the problem regularly
[18:34] <arigo> translate_pypy.py appears to be fast enough now,
[18:34] <arigo> even with the label-ignorant flow space
[18:38] <pedronis> arigo: does it make sense to make simplfying=True the default now for the translator?
[18:38] <arigo> guess so
[18:42] <arigo> I cannot figure out why __mm_mul_perform_call() calls W_NoneObject.__mm_mul()
[18:45] <arigo> ah wait
[18:46] <arigo> I guess it's actually another method, but we reuse function objects
[18:47] <arigo> yes sorry. It's the one got from W_Root.
[18:49] <pedronis> yes
[19:00] arigo (~arigo@d213-103-137-124.cust.tele2.ch) left irc: "back in a moment"
[19:11] arigo (~arigo@d213-103-137-124.cust.tele2.ch) joined #pypy.
[19:19] stakkars (lupvqz@i528C1B01.versanet.de) left irc: Read error: 60 (Operation timed out)
----- silence for 27 minutes ----- [19:46] Nick change: pedronis -> pedronis_afk
[19:59] arigo (~arigo@d213-103-137-124.cust.tele2.ch) left irc: "again"
----- silence for 45 minutes ----- [20:44] Nick change: pedronis_afk -> pedronis
----- silence for 32 minutes ----- [21:16] bzimmer (~bzimmer@c-24-13-11-91.client.comcast.net) joined #pypy.
----- silence for 19 minutes ----- [21:35] bzimmer (~bzimmer@c-24-13-11-91.client.comcast.net) left irc:
----- silence for 16 minutes ----- [21:51] bzimmer (~bzimmer@c-24-13-11-91.client.comcast.net) joined #pypy.
----- silence for 16 minutes ----- [22:07] bzimmer (~bzimmer@c-24-13-11-91.client.comcast.net) left irc:
----- silence for 16 minutes ----- [22:23] Continuity (~kittish@host81-155-190-14.range81-155.btcentralplus.com) joined #pypy.
----- silence for 19 minutes ----- [22:42] bzimmer (~bzimmer@c-24-13-11-91.client.comcast.net) joined #pypy.
[22:44] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: Read error: 113 (No route to host)
[00:00] --- Sun Mar 6 2005