[01:22] _hannes (rppcnsbq@i528C18A2.versanet.de) left irc: "utz utz utz"
[01:28] arigo (~arigo@vicky.ecs.soton.ac.uk) left irc: "leaving"
----- silence for 21 minutes ----- [01:49] <stakkars> arigo: anyway,now it works,and it works very nicely. Moving to other stuff...
----- silence for 47 minutes ----- [02:36] Continuity (~kittish@host81-153-48-22.range81-153.btcentralplus.com) left irc: Read error: 60 (Operation timed out)
----- silence for 19 minutes ----- [02:55] stakkars (~tismer@82.144.60.19) left irc: Read error: 110 (Connection timed out)
[02:56] SamB (naesten@r226120.res.Lehigh.EDU) joined #pypy.
----- silence for 1 hr and 2 minutes ----- [03:58] 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 3 hr and 22 minutes ----- [07:20] idnar (mithrandi@idnar.user) left irc: Read error: 110 (Connection timed out)
----- silence for 1 hr and 55 minutes ----- [09:15] idnar (mithy@idnar.user) joined #pypy.
----- silence for 1 hr and 32 minutes ----- [10:47] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
----- silence for 19 minutes ----- [11:06] dlk (~dlk@walter.ita.chalmers.se) joined #pypy.
[11:07] dlk (~dlk@walter.ita.chalmers.se) left irc: Remote closed the connection
[11:07] dlk (~dlk@walter.ita.chalmers.se) joined #pypy.
[11:08] dlk (dlk@walter.ita.chalmers.se) left #pypy.
----- silence for 19 minutes ----- [11:27] arigo (~arigo@d213-103-140-139.cust.tele2.ch) joined #pypy.
[11:40] <hpk> arigo: good morning
[11:40] <arigo> good morning
[11:41] <hpk> regarding leysin: i'll make a decision by the end of the week when the dust has settled
[11:41] <hpk> so i am not coming before sunday at least :-)
[11:42] <arigo> ok!
[11:42] <hpk> something else: what do think about what i reported from the croquet/impara people?
[11:43] <hpk> (assuming you read it although it was on pypy-funding :-)
[11:43] <arigo> ah then I must have missed it
[11:44] <hpk> it's called "Impara meeting 22nd Feb 2005"
[11:44] Action: arigo reads
[11:49] <arigo> that's an interesting collaboration possibility
[11:51] <hpk> it remains to be seen at what level there could be interactions between pypy and squeak/croquet, though
[11:51] <hpk> e.g. should pypy generate squeak-bytecode?
[11:54] <hpk> or should we try a smalltalk frontend? :-)
[11:55] <arigo> I don't know yet
[11:55] <arigo> I guess this has to be discussed with the Croquet guys
[11:55] <arigo> I'd rather provide a smalltalk backend
[11:56] <hpk> i guess that they will want this, too
[11:56] <arigo> well, there are alternatives too
[11:56] <arigo> it'd be relatively easy to try another approach, like
[11:56] <arigo> keeping all PyPy minus the bytecode format
[11:57] <arigo> and generate squeak-bytecode, as you suggest.
[11:57] <arigo> I didn't think about it too much, but it'd be nice in general to experiment with other bytecode formats,
[11:57] <arigo> as this is only a matter of writing a new subclass of Frame or even PyFrame
[11:58] <arigo> (plus a compiler of course)
[11:58] <hpk> yes, yet another approach is to have both pypy and squeak running in the same process
[11:58] <hpk> and build a cross-language bridge
[11:58] <arigo> yes, though that approach is "the CPython way" :-)
[11:59] <hpk> yes, but the question is anyway, how to represent the squeak objects/api within python
[12:00] <arigo> a very good question
[12:00] mwh2 (~user@modem-141.erendis.dialup.pol.co.uk) joined #pypy.
[12:00] <hpk> this question is somewhat independent from how it is achieved at the loewr level
[12:00] <arigo> let's not forget we don't even know how we'll implement e.g. the os module yet
[12:01] <mwh2> arigo: just quickly, re the mro bug: aaaaargh
[12:01] <arigo> mwh2: of course you forgot the check the file box on SF
[12:01] <mwh2> actually
[12:01] <arigo> mwh2: aaaaargh?
[12:02] <mwh2> i may have forgotten to attach the file at all
[12:02] <mwh2> def mro(self):
[12:02] <mwh2> return 1
[12:02] <mwh2> boom!
[12:02] <mwh2> def mro(self):
[12:02] <arigo> :-)
[12:02] <mwh2> return [1]
[12:02] <mwh2> boom a bit later!
[12:02] <arigo> well, that's aaarghish, but not difficult to fix, is it?
[12:03] <mwh2> no
[12:03] <arigo> but then we need to come up with a definition of "sane MRO"
[12:03] <mwh2> but it's so very clear that noone thought about sneaky mro() functions
[12:03] <arigo> :-)
[12:04] <mwh2> i've attached the file not
[12:04] <mwh2> now
[12:05] <arigo> I think CPython is not ready for the idea that subtyping != C structure extension
[12:05] <arigo> so we should somehow check that the mro doesn't break that assumption
[12:05] <mwh2> yes
[12:06] <mwh2> so should check that PySequence_Tuple doesn't fail
[12:06] <mwh2> that each element of the tuple is a type
[12:07] <mwh2> that the solid_base of each type in the tuple is a supertype of the solid_base of the type we're building
[12:07] <arigo> uh?
[12:07] <mwh2> hmm?
[12:07] <arigo> that condition doesn't make sense to me
[12:08] <mwh2> which? the last?
[12:08] <arigo> yes
[12:08] <mwh2> how would you phrase it?
[12:08] <arigo> (I won't even pronounce the words 'old-style' and 'class' together for now)
[12:09] <arigo> what would be a the test for C structure extension?
[12:09] <mwh2> is that the solid_base stuff?
[12:10] <arigo> well, more or less
[12:10] <arigo> class A(object); class B(object); class C(A,B)
[12:10] <arigo> C->tp_base == A (I guess)
[12:10] <arigo> but B is allowed in C->tp_mro
[12:11] <mwh2> solid_base != tp_base
[12:11] <arigo> oh sorry
[12:11] <mwh2> solid_base is tp_base iterated until you get somthing that changes the memory layout
[12:11] <mwh2> it's a function in typeobject.c
[12:12] <arigo> so the super type in the C sense...
[12:12] <mwh2> yeah, i guess so
[12:13] <arigo> err no
[12:13] <arigo> solid_base(A) is the most super Python type that has the same memory layout as A, no?
[12:14] <mwh2> err, maybe
[12:15] <mwh2> i have to admit the implementation of that function confuses me
[12:15] <arigo> with this definition I understand your condition at least :-)
[12:15] <arigo> me too
[12:16] idnar (mithy@idnar.user) left irc: "*sigh* rebooting"
[12:17] <mwh2> after a small hack
[12:17] <mwh2> >>> class B(dict):
[12:17] <mwh2> ... pass
[12:17] <mwh2> ...
[12:17] <mwh2> [44751 refs]
[12:17] <mwh2> >>> B.__solid__
[12:17] <mwh2> <type 'dict'>
[12:17] <mwh2>
[12:17] <mwh2> which suggests it is the thing we want
[12:18] <arigo> indeed
[12:18] <mwh2> though:
[12:18] <mwh2> >>> class B(dict):
[12:18] <mwh2> ... pass
[12:18] <mwh2> ...
[12:18] <mwh2> [44751 refs]
[12:18] <mwh2> >>> B.__solid__
[12:18] <mwh2> <type 'dict'>
[12:18] <mwh2>
[12:18] <mwh2> sorry
[12:18] <mwh2> >>> class B(dict):
[12:18] <mwh2> ... __slots__ = ['a']
[12:18] <mwh2> ...
[12:18] <mwh2> [44797 refs]
[12:18] <mwh2> >>>
[12:18] <mwh2> [44797 refs]
[12:19] <mwh2> >>> B.__solid__
[12:19] <mwh2> <class '__main__.B'>
[12:19] <mwh2>
[12:19] <mwh2> is that a problem?
[12:19] <arigo> makes sense
[12:19] <arigo> I don't think so
[12:19] <mwh2> ok, good
[12:20] <arigo> you can't make class D(B,C)
[12:20] <arigo> if C is
[12:20] <arigo> class C(dict):
[12:20] <arigo> __slots__ = ['hello']
[12:20] <arigo>
[12:21] <mwh2> sure
[12:21] <mwh2> but does it mess up my sanity check above?
[12:21] <mwh2> no, it doesn't, does it?
[12:21] <mwh2> good
[12:24] <arigo> raah
[12:24] <arigo> I renamed extra_ivars() into same_instance_layout() for sanity
[12:24] <arigo> (negating the return statements)
[12:24] <mwh2> ah, good :)
[12:25] <arigo> but now I'm not sure same_instance_layout() is transitive
[12:25] idnar (mithy@idnar.user) joined #pypy.
[12:32] <arigo> here is an example:
[12:32] <arigo> class A(object):
[12:32] <arigo> __slots__ = ['__weakref__']
[12:32] <arigo> class B(A): pass
[12:32] <arigo>
[12:33] <arigo> I think that !extra_ivars(B, A) && !extra_ivars(A, object)
[12:33] <arigo> but extra_ivars(B, object)
[12:33] <arigo> and indeed,
[12:33] <arigo> >>> B.__solid__
[12:33] <arigo> <class '__main__.B'>
[12:34] <arigo> >>> class C(object):
[12:34] <arigo> ... __slots__ = ['__weakref__', '__dict__']
[12:35] <arigo> >>> C.__solid__
[12:35] <arigo> <type 'object'>
[12:35] <arigo> which is a bit strange, as C and B are essentially the same
[12:41] mwh2 (~user@modem-141.erendis.dialup.pol.co.uk) left irc: Read error: 60 (Operation timed out)
----- silence for 19 minutes ----- [13:00] mwh2 (~user@modem-238.erellont.dialup.pol.co.uk) joined #pypy.
[13:01] <mwh2> sorry, didn't log out before
[13:01] <mwh2> did i miss much?
[13:01] <arigo> I was musing about __solid__
[13:01] <arigo> same_instance_layout() is not transitive
[13:02] <arigo> there is a case where Python denies a class construction that would be valid
[13:02] <mwh2> it's not?
[13:02] <mwh2> araragh
[13:02] <mwh2> you have an example?
[13:02] <arigo> class A(object): __slots__ = ['__weakref__']
[13:02] <arigo> class B(A): pass
[13:02] <arigo> >>> B.__solid__
[13:02] <arigo> <class '__main__.B'>
[13:03] <mwh2> boggle
[13:03] <arigo> this is because the weakref and the dict are created in the wrong order for same_instance_layout()...
[13:03] <arigo> but if you fix this, then B.__solid__ is object and you can use it normally
[13:03] <arigo> class D(int, B)
[13:03] <mwh2> oh
[13:03] <mwh2> so this is just a little bug in same_instance_layout?
[13:03] <arigo> should work, does work, but cannot be created because of that "bug"
[13:03] <arigo> I think so
[13:04] <arigo> I didn't look at what strange things you can do with tp_itemsize yet
[13:05] <mwh2> i suspect there might be some over-restrictiveness there too
[13:06] <mwh2> though you can't have slots when subclassing a type with tp_itemsize != 0, right?
[13:06] <arigo> right
[13:06] <arigo> you can't have weakrefs either
[13:06] <arigo> only a dict
[13:06] <mwh2> yeah
[13:07] <mwh2> tp_dictoffset = -4 or so, right?
[13:07] <arigo> yes
[13:07] <mwh2> i presume you *could* have tp_dictoffset = -8, tp_weaklistoffset = -4?
[13:07] <mwh2> in principle, at least
[13:07] <arigo> no, tp_weaklistoffset cannot be negative (no support)
[13:07] <mwh2> yes, but that support could be added
[13:08] <arigo> yes
[13:08] <mwh2> not saying we should, but just trying to clear my understanding
[13:08] <arigo> I guess the solid base of class A(str) is A instead of str now
[13:08] <arigo> uh
[13:08] <arigo> maybe not
[13:09] <mwh2> ooh
[13:09] <arigo> the "stricter rule" is not so strict
[13:09] <mwh2> oh
[13:09] <mwh2> a bug in my __solid__ hack
[13:09] <arigo> it means "same size before the variable part, same variable item size" and doesn't care about what comes after the variable part (only the dict can, so far)
[13:10] <mwh2> >>> class A(str): pass
[13:10] <mwh2> ...
[13:10] <mwh2> [44520 refs]
[13:10] <mwh2> >>> A.__solid__
[13:10] <mwh2> <class '__main__.A'>
[13:10] <mwh2>
[13:10] <arigo> ah
[13:10] <mwh2> (that's not the bug, btw, the bug is refcounting or lack of)
[13:10] <arigo> why??
[13:10] <mwh2> there's a dict in instances of A?
[13:11] <arigo> yes but not accounted for in tp_size, I expect
[13:11] <arigo> (tp_basicsize I mean)
[13:11] <mwh2> no, that doesn't make sense
[13:12] <arigo> uh??
[13:12] <arigo> >>> str.__basicsize__
[13:12] <arigo> 24
[13:12] <arigo> >>> A.__basicsize__
[13:12] <arigo> 28
[13:12] <arigo> ahhhh, (tp_basicsize+N*tp_itemsize) is the total size
[13:12] <mwh2> well, yes that makes some sense
[13:12] <arigo> the 4 extra bytes are at the end actually
[13:12] <mwh2> indeed
[13:13] <arigo> I'd have expected tp_basicsize to give the offset to the variable part,
[13:13] <arigo> but I guess that's just a wrong expectation.
[13:13] <arigo> now why would "A.__solid__==str" hurt?
[13:13] <mwh2> extra_ivars ignores an additional dict and weakref var, but not in the case of tp_itemsize !== 0
[13:13] <mwh2> now
[13:13] <mwh2> why?
[13:14] <mwh2> i think i've just asked the same question as you
[13:14] <arigo> class A(str); class B(str); class C(A,B)
[13:14] <arigo> lay-out conflict
[13:14] <arigo> doesn't make much sense so far...
[13:14] <mwh2> uh, really?
[13:15] <mwh2> yes, would seem so
[13:15] <arigo> mess**10
[13:15] <mwh2> can we just ban subclassing builtin types again?
[13:15] <mwh2> i'm really not sure it's worth it
[13:15] <arigo> we should, shouldn't we?
[13:16] <arigo> Samuele suggested that Python 2.2 should have tried to make types more like classes instead of the other way around
[13:16] <mwh2> yes
[13:16] <arigo> I very much doubt that the precise semantics of all this are documented.
[13:16] <mwh2> oh good grief no
[13:17] <mwh2> def sc(b): return type('', (b,) {})
[13:17] <mwh2> that sc(sc(str), sc(str)) fails doesn't seem intended to me
[13:17] <mwh2> well, ish
[13:18] <arigo> ish indeed
[13:18] <mwh2> def sc(*b): return type('', b, {})
[13:18] <mwh2> is better :)
[13:18] <arigo> :-)
[13:19] <arigo> of course in PyPy you can do that
[13:19] <mwh2> of course
[13:19] <arigo> bouh
[13:20] <mwh2> we don't really do the equivalent of tp_itemsize != 0, for starters
[13:20] <arigo> yes
[13:20] <arigo> what about forgetting about it and doing the mro sanity check you mentioned?
[13:20] <arigo> what about... drums... old-style classes?
[13:20] <mwh2> well, yes, that would be an improvement
[13:20] <mwh2> i think they just add irritation, not anything profound
[13:22] <mwh2> .me also
[13:22] Action: mwh2 also notices that for custom metaclasses that don't define an mro() method, the control flow still goes round the houses
[13:24] <arigo> typeobject.c and import.c are both huge and both implement semantics that show up to the user but that aren't precisely documented
[13:24] <mwh2> yes, indeed
[13:24] <arigo> let's cvs rm these two files and see what occurs :-)
[13:24] <mwh2> i'm happier in typeobject.c than import.c, though
[13:24] <mwh2> anyway, should go again
[13:24] mwh2 (~user@modem-238.erellont.dialup.pol.co.uk) left irc: "biab"
[13:25] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[13:25] <arigo> hi
[13:25] <arigo> you just missed more funny CPython behaviors in typeobject.c
[13:26] <pedronis> hi
[13:26] <pedronis> I was reading the log
[13:28] tea (~tea@cap011-170.kcn.ne.jp) joined #pypy.
[13:30] <pedronis> arigo: I think we discussed that while implementing slots, the semantics of what layouts are permitted
[13:30] <pedronis> are very messy in CPython, it does all these
[13:31] <pedronis> size based computation, but it's not always clear
[13:31] <pedronis> what's intended or not behind them
[13:46] Action: arigo -> lunch
[13:46] arigo (~arigo@d213-103-140-139.cust.tele2.ch) left irc: "Leaving"
----- silence for 49 minutes ----- [14:35] Action: pedronis see you
[14:35] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Remote closed the connection
[14:44] arigo (~arigo@d212-152-19-138.cust.tele2.ch) joined #pypy.
[14:46] mwh2 (~user@modem-188.erendis.dialup.pol.co.uk) joined #pypy.
[14:52] <arigo> itertools.islice(range(10), -1)
[14:52] <arigo> ValueError: Stop argument must be an integer or None.
[14:52] <arigo> misleading error message...
[14:52] <mwh2> i think i noticed that, yes
----- silence for 18 minutes ----- [15:10] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[15:23] mwh2 (~user@modem-188.erendis.dialup.pol.co.uk) left irc: "bye"
[15:35] poseidon (~poseidon@host66-30.pool8174.interbusiness.it) joined #pypy.
----- silence for 18 minutes ----- [15:53] stakkars (~tismer@82.144.60.19) joined #pypy.
[15:59] <arigo> hi
[16:09] <stakkars> hi!
[16:18] <stakkars> C99 :-)
----- silence for 37 minutes ----- [16:55] _hannes (~yuuhu@i3ED6B1A4.versanet.de) joined #pypy.
----- silence for 23 minutes ----- [17:18] ludal (~ludal@logilab.net2.nerim.net) left irc: "Download Gaim: http://gaim.sourceforge.net/";
----- silence for 23 minutes ----- [17:41] idnar (mithy@idnar.user) left irc: Remote closed the connection
----- silence for 44 minutes ----- [18:25] arigo (~arigo@d212-152-19-138.cust.tele2.ch) left irc: "reboots"
[18:31] arigo (~arigo@d212-152-19-138.cust.tele2.ch) joined #pypy.
[18:34] <pedronis> I have checked-in code that uses structural comparison to decide whether to bump a rev number when in doubt
----- silence for 27 minutes ----- [19:01] yuuh (smpkcmo@i528C1F27.versanet.de) joined #pypy.
[19:07] idnar (mithrandi@idnar.user) joined #pypy.
[19:07] _hannes (~yuuhu@i3ED6B1A4.versanet.de) left irc: Read error: 60 (Operation timed out)
----- silence for 23 minutes ----- [19:30] <stakkars> pedronis: interesting!
[19:30] <stakkars> I see how you build the structure info. Where do you compare it, then?
[19:31] <pedronis> in Classdef generalize_attr
[19:32] <stakkars> Ah, I understand. Really nice.
[19:33] <stakkars> might that partially also provide a way to decide about flow graph caching?
[19:48] <pedronis> stakkars: I don't know
[19:48] <pedronis> the problem with caching the basic flow graphs (even without annotation entering the scene)
[19:48] <pedronis> is the computed constants
[19:48] <pedronis> even if a function has not changed
[19:48] <pedronis> some global may have
[19:49] <pedronis> wich means that the value of some constants in the graph
[19:49] <pedronis> would need to change
[19:49] <stakkars> yes. And the computed constants need to be computed again, in order to find out whether they changed or not. That is, after recomputing flow graphs, we know if we wasted time, but not before.
[19:50] <stakkars> maybe there is a way to track the globals.
[19:50] <pedronis> well, there may be a way
[19:51] <pedronis> to go through the function bytecode and the flowgraph just once
[19:51] <pedronis> and check the constants
[19:51] <pedronis> instead of doing the whole iterative process
[19:51] <pedronis> again
[19:52] <stakkars> this was what I proposed, but you said it is more complicated, I'd have to do computation.
[19:53] <pedronis> yes
[19:53] <arigo> pedronis: sorry for lagging behind, but why does the snippet you checked in 2 days (with Stk and EC) ago fail to annotate?
[19:53] <stakkars> resp., what do you mean by flow graph? I thought building it is the whole expensive thing?
[19:53] <pedronis> because we ignored revision numbers
[19:53] <pedronis> when updating attributes
[19:54] <pedronis> so changes to classes
[19:54] <pedronis> never reached places
[19:54] <pedronis> that got an instance out of an attribute
[19:55] <pedronis> now we don't ignore rev numbers anymore
[19:55] <pedronis> in this case
[19:55] <pedronis> but we have to be careful with recursive data structures
[19:56] <arigo> well
[19:56] <arigo> I still believe that the real problem is that contains() is overridden in SomeInstance to completely ignore rev numbers
[19:57] <pedronis> that's not the case anymore
[19:57] <arigo> until I'm proven otherwise of course :-)
[19:57] <pedronis> that is what I changed
[19:57] <pedronis> that solved the Stk and EC problem
[19:57] <stakkars> it is true, I just studied that
[19:57] <pedronis> but then make_eo would get into an infinite loop of rev bumping
[19:58] <pedronis> so I needed a way to solve that other problem
[19:59] <pedronis> I think the last solution checked in makes sense
[19:59] <pedronis> but is is surely expensive
[19:59] <pedronis> I don't know in practice how often you will have to compute structures
[20:01] <pedronis> now the tests pass
[20:04] <arigo> and why is not bumping rev number safe?
[20:04] <pedronis> because considering the type of the whole object graph
[20:05] <pedronis> hanging from the instance
[20:05] <pedronis> nothing has changed
[20:05] <pedronis> so the old getattr answers are still valid
[20:05] <pedronis> that's with the last code
[20:06] <pedronis> the criteria in the checking discussed on pypy-dev
[20:06] <pedronis> was misleading
[20:06] <pedronis> now it is only used to narrow the cases were we need to consider the whole structure
[20:08] Action: arigo -> running for train
[20:08] arigo (~arigo@d212-152-19-138.cust.tele2.ch) left irc: "Leaving"
[20:23] mwh2 (~user@modem-148.erendis.dialup.pol.co.uk) joined #pypy.
[20:24] mwh2 (~user@modem-148.erendis.dialup.pol.co.uk) left irc: Client Quit
----- silence for 38 minutes ----- [21:02] Action: pedronis leaving the office
[21:02] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "ChatZilla 0.9.61 [Mozilla rv:1.7.3/20041007]"
----- silence for 18 minutes ----- [21:20] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) left irc: Read error: 54 (Connection reset by peer)
[21:20] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 48 minutes ----- [22:08] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[22:17] <pedronis> stakkars: it seems there's a problem with the logs archive server
[22:26] stakkars (~tismer@82.144.60.19) left irc: Read error: 110 (Connection timed out)
----- silence for 47 minutes ----- [23:13] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: "Leaving"
[23:16] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy.
[00:00] --- Fri Mar 4 2005