[00:59] Continuity (kittish@host81-155-190-218.range81-155.btcentralplus.com) left irc: Remote closed the connection
[01:02] _hannes (srcipo@i528C13CA.versanet.de) left irc: "utz utz utz"
----- silence for 3 hr and 25 minutes ----- [04:27] }{`P^}IT (HAKAN06__@69.157.237.111) joined #pypy.
[04:27] }{`P^}IT (HAKAN06__@69.157.237.111) left #pypy.
[04:31] [}{`P^}IT!HAKAN06__@69.157.237.111] Come watch me on my webcam and chat /w me :-) http://69.157.237.111:4072/me.mpg
----- silence for 27 minutes ----- [04:58] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: Read error: 60 (Operation timed out)
[05:13] Fade (~fade@outrider.deepsky.com) joined #pypy.
----- silence for 34 minutes ----- [05:47] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy.
----- silence for 18 minutes ----- [06:05] idnar (mithrandi@idnar.user) left irc: Operation timed out
----- silence for 42 minutes ----- [06:47] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: Read error: 60 (Operation timed out)
----- silence for 1 hr and 4 minutes ----- [07:51] idnar (mithy@idnar.user) joined #pypy.
----- silence for 34 minutes ----- [08:25] adim (~adim@logilab.net2.nerim.net) joined #pypy.
----- silence for 2 hr and 44 minutes ----- [11:09] stakkars (~tismer@82.144.60.19) joined #pypy.
----- silence for 59 minutes ----- [12:08] arigo (~arigo@vicky.ecs.soton.ac.uk) joined #pypy.
----- silence for 25 minutes ----- [12:33] arigo (~arigo@vicky.ecs.soton.ac.uk) left irc: "leaving"
[12:44] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy.
[12:54] <stakkars> if some annotator guru reads this:
[12:55] <stakkars> maybe we have some error atline 186 of binaryop.py?
[12:55] <stakkars> def union((tup1, tup2)):
[12:55] <stakkars> if len(tup1.items) != len(tup2.items):
[12:55] <stakkars> return SomeObject()
[12:56] <stakkars> I think this is a bit big of a union, to completely trash the tuple-ness?
[13:01] pedronis (~Samuele_P@c-298b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 20 minutes ----- [13:21] pedronis (~Samuele_P@c-298b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041107]"
[13:35] arigo (~arigo@d213-103-147-153.cust.tele2.ch) joined #pypy.
----- silence for 32 minutes ----- [14:07] arigo_ (~arigo@vicky.ecs.soton.ac.uk) joined #pypy.
[14:08] arigo (~arigo@d213-103-147-153.cust.tele2.ch) left irc: Nick collision from services.
[14:08] Nick change: arigo_ -> arigo
[14:18] mwh2 (~user@modem-170.erendis.dialup.pol.co.uk) joined #pypy.
[14:20] <stakkars> hi armin
[14:20] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[14:20] <arigo> hi!
[14:21] <stakkars> in annotator, binaryop, union(tup1, tup2):
[14:21] <stakkars> why do we return SomeObject(), when the lengths don'tmatch?
[14:21] <stakkars> that leads to a lot of SomeObjects I think
[14:22] <arigo> SomeTuple is only for tuples of known length
[14:22] <mwh2> arigo: i've just attached something completely over the top and fairly silly to our favourite bug
[14:22] <stakkars> ah, I see
[14:23] <pedronis> is not that useful to know that something is just a tuple
[14:23] <pedronis> without info about the lenght and types
[14:24] <pedronis> in translate_pypy0 there was just one case where that code played a role
[14:24] <pedronis> with the constructor of Exception that set .args to the arguments tuple
[14:25] <pedronis> it was easy enough to make the construction uniform
[14:26] <stakkars> at least it tells about sequence-ness.
[14:26] <stakkars> I just wondered if this would influence the various places where we have an arg tuple.
[14:27] <stakkars> and it was misleading since dicts are merged without considering lengths.
[14:28] <pedronis> but we usually use lists for that kind of code
[14:28] <pedronis> for example Arguments takes lists
[14:28] <pedronis> in fact there was one place were a tuple was passed directly and that was a problem
[14:30] <stakkars> I see. I had annotation of appspace programs in mind, which is not the topic, but could be considered, too.
[14:32] <mwh2> i think that's for next year...
[14:34] <pedronis> stakkars: tuple in python sense and rpython sense are different beasts
[14:35] <arigo> mwh2: nice theorem
[14:35] <arigo> mwh2: but obviously, my doubts are also about the sanity of solid_base and the partial order relation in typeobject.c
[14:36] <mwh2> arigo: well, yes
[14:36] <mwh2> it's a start
[14:36] <arigo> I guess it shows how typeobject.c ought to be fixed
[14:39] <mwh2> i'd also like to extend this to work out more accurately when __base__ assignment is safe
[14:39] <mwh2> __bases__, rather
[14:40] <arigo> I see
[14:40] <mwh2> do you think that rewriting chunks of typeobject.c is the way forward?
[14:41] <arigo> hum
[14:41] <arigo> probably
[14:42] <stakkars> already a pretty complicated beast.
[14:42] <mwh2> or at least some selective renaming
[14:42] <mwh2> well, right now i don't think *anyone* really knows what's going on
[14:42] <mwh2> not even guido
[14:43] <mwh2> if we get to the point where me and arigo have a clue what's going on, that's progress :)
[14:43] <stakkars> I think I did, for a while, when porting stackless, and I had to hack on this. :)
[14:43] <arigo> I guess there is only some collective knowledge left, i.e. if we put any 3 of {samuele, you, guido, tim, me} together they can work it out :-)
[14:43] <mwh2> i think i understand bits and pieces of it
[14:44] <arigo> tah, set.update({stackkars})
[14:44] <mwh2> stakkars: def sc(*types): return type('', types, {})
[14:44] <mwh2> sc(sc(str), sc(str)) fails
[14:45] <pedronis> btw, I think it probably works with the new Jython new-style classes
[14:46] <mwh2> pedronis: does jython have this 'variable length type' concept?
[14:46] <mwh2> that's where this problem lies
[14:46] <stakkars> mwh2: is this true for 2.4, or 2.3 also?
[14:46] <pedronis> no, that's why I was probably able
[14:47] <stakkars> i.e. do I need to look into 2.4?
[14:47] <pedronis> to use a far simpler model
[14:47] <mwh2> stakkars: i think this is 2.2 onwards, but i'm not sure
[14:47] <stakkars> ok, 2.3 barfs
[14:47] <mwh2> i think arigo found the problem, too
[14:48] <mwh2> some ordering problem in extra_ivars
[14:48] <mwh2> but it's all a bit headache inducing
[14:49] <pedronis> of course it works in PyPy too at the moment
[14:49] <mwh2> i think i like the idea of this 'layout compatiblity' concept
[14:50] <mwh2> then we can define what's allowed in terms of that
[14:50] <mwh2> and hopefully prove an algorithm for determining it
[14:50] <mwh2> and also prove that it really means what it claims to mean
[14:50] <mwh2> divide & conquer
[14:51] <pedronis> whta's the bug number again?
[14:51] <stakkars> yes, it's extra_ivars, I think, which recognizes an extra dict, therefore solid_base returns the type and not the base.
[14:52] <mwh2> pedronis: 1153075
[14:52] <arigo> is there a case where tp_dictoffset < -4 ?
[14:52] <arigo> (i.e. in variable-length types, can the dict possibly not be at the very end?)
[14:53] <stakkars> might depend on weak-ref
[14:53] <arigo> you can't weakref any subclass of var-length type
[14:54] <stakkars> yes, but could use the same trick
[14:54] <mwh2> arigo: yeah, when sizeof(PyObject*) != 4 :)
[14:54] <arigo> mwh2: well yes but :-)
[14:55] <mwh2> no, bascially
[14:55] <mwh2> in general, i don't really see a reason why you can't do the offset < 0 => count from the end with *all* slots
[14:56] <mwh2> tp_weaklistoffset and user defined slots
[14:56] <mwh2> istm it would be more consistent
[14:59] <arigo> definitely
[14:59] <mwh2> can you print this conversation out, roll it up and beat guido over the head with it at pycon? :)
[14:59] <arigo> combined with a clean-up, this would be worth a larger typeobject.c patch
[14:59] <arigo> :-)
[15:00] <mwh2> oh sure
[15:00] <mwh2> but i'd still like to check my patch in
[15:01] <mwh2> maybe without the subtle
[15:01] <mwh2> if (!PyType_IsSubtype(solid, solid_base(t))) {
[15:01] <mwh2>
[15:01] <mwh2> bit, though
[15:02] <arigo> makes sense
[15:03] <mwh2> the subtle bit "seems to be right", but...
[15:03] <arigo> it should go in 2.4 maint, but we should make it fully correct before 2.5, ideally
[15:05] <mwh2> well, the "unsubtle bit" is surely safe
[15:05] <arigo> sure, the problem is about breaking user code that seems to work now
[15:05] <mwh2> should check with anthony, of course
[15:06] Action: mwh2 hits sf with a well-worn stick
[15:13] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) left irc: "Leaving"
[15:19] dialtone (~dialtone@host116-56.pool80117.interbusiness.it) joined #pypy.
----- silence for 18 minutes ----- [15:37] mwh2 (~user@modem-170.erendis.dialup.pol.co.uk) left irc: "wanders off"
[15:44] <pedronis> hpk: ?
[15:48] Continuity (~kittish@host81-155-190-218.range81-155.btcentralplus.com) joined #pypy.
[15:52] <stakkars> I'm asking myself if sc(sc(str), sc(str)) *should* work, or what is the criteria.
[15:52] <stakkars> It would mean to merge __dict__ as a special rule,right?
[15:54] <arigo> well,
[15:54] <arigo> sc(sc(object), sc(object)) works
[15:54] <arigo> the same rule (merge the __dict__) should just apply.
[15:54] <stakkars> aaaarghh
[15:56] <pedronis> sc(sc(dict),sc(dict)) works too
[15:56] <arigo> sure
[15:56] <arigo> it works for everything apart from variable-sized types
[15:56] <stakkars> that's of course bad.
[15:57] <stakkars> so we needto handle the variable-sized thiongs once and forever
[15:59] <stakkars> well, in Stackless python, sc(sc(type), sc(type)) works! ;-)
[16:00] <stakkars> I special-cased that, because I wanted slots in types.
[16:01] <stakkars> was a bit bind-boggling, because the types *has* slots, which it *produces* on its instance, another type...
[16:02] <stakkars> aehhh, and in regular Python, too. Huh? Types *are* var-sized.
[16:02] Jerub (~gideon@CPE-203-45-251-238.qld.bigpond.net.au) joined #pypy.
[16:03] <Jerub> hi, I've been playing with pyrex, and the demo in the howtopypy page doesn't work with pyrex.
[16:04] <Jerub> print Translator(test.is_perfect_number).pyrex() has this as line 3:
[16:04] <Jerub> cdef int is_perfect_number__-4854089c(int i_n_1):
[16:04] <Jerub> that looks like an int overflow bug to me.
[16:07] <Jerub> anyway, goodnight.
[16:11] <arigo> Jerub: oops, thanks
[16:12] <arigo> I guess it's a bug that only show up on specific platforms
[16:14] <arigo> fixed, thanks for the report
----- silence for 30 minutes ----- [16:44] idnar (mithy@idnar.user) left irc: "kbye"
[16:55] faassen (~faassen@213.56.215.195) joined #pypy.
[16:55] <faassen> is codespeak svn down?
[16:58] <arigo> faassen: seems so
[16:58] Action: arigo restarts it
[16:59] <faassen> thanks.
[16:59] <arigo> ah, it's up again
[16:59] <arigo> I didn't restart it myself
[17:06] <faassen> ah, okay.
[17:07] <faassen> hm, if the svn password the same as the login you have to the machine or something else?
[17:07] <faassen> I so infrequently need it i keep forgetting.
[17:07] _hannes (~yuuhu@i528C13CA.versanet.de) joined #pypy.
[17:08] <arigo> it's the same one
[17:21] <faassen> thanks, it works. :)
----- silence for 28 minutes ----- [17:49] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "ChatZilla 0.9.61 [Mozilla rv:1.7.3/20041007]"
[17:52] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[17:57] Jerub (~gideon@CPE-203-45-251-238.qld.bigpond.net.au) got netsplit.
[17:57] jacob22 (jacob@enzo.strakt.com) got netsplit.
[17:58] Jerub (~gideon@CPE-203-45-251-238.qld.bigpond.net.au) returned to #pypy.
[17:59] arigo (~arigo@vicky.ecs.soton.ac.uk) left irc: "bye"
[18:02] idnar (mithrandi@idnar.user) joined #pypy.
[18:03] jacob22 (jacob@enzo.strakt.com) got lost in the net-split.
[18:10] jacob22 (jacob@62.119.131.75) joined #pypy.
----- silence for 27 minutes ----- [18:37] adim (adim@logilab.net2.nerim.net) left #pypy.
----- silence for 44 minutes ----- [19:21] _hannes (~yuuhu@i528C13CA.versanet.de) got netsplit.
[19:21] mwh (~user@pc150.maths.bris.ac.uk) got netsplit.
[19:24] mwh2 (~user@modem-15.erendis.dialup.pol.co.uk) joined #pypy.
[19:25] <mwh2> ok, typeobject.c quiz question of the evening!
[19:26] <mwh2> why do compatible_for_assignment and solid_base use apparently entirely different algorithms?
[19:26] _hannes (~yuuhu@i528C13CA.versanet.de) returned to #pypy.
[19:26] mwh (~user@pc150.maths.bris.ac.uk) returned to #pypy.
[19:29] mwh (~user@pc150.maths.bris.ac.uk) got netsplit.
[19:29] _hannes (~yuuhu@i528C13CA.versanet.de) got netsplit.
[19:30] mwh (~user@pc150.maths.bris.ac.uk) returned to #pypy.
[19:32] <pedronis> mwh: did you do __bases__ assigment or also __class__?
[19:32] faassen (~faassen@213.56.215.195) left irc: "Download Gaim: http://gaim.sourceforge.net/";
[19:35] _hannes (~yuuhu@i528C13CA.versanet.de) got lost in the net-split.
[19:39] mwh (~user@pc150.maths.bris.ac.uk) got netsplit.
[19:40] mwh (~user@pc150.maths.bris.ac.uk) returned to #pypy.
[19:44] <mwh2> i just did __bases__
[19:47] <pedronis> I see
[19:47] <mwh2> and that's wrong too, probably
[19:47] <mwh2> well
[19:47] <mwh2> it's over-restrictive
[19:49] <pedronis> well, yes it would make sense to have onyl one approach
[19:52] mwh2 (~user@modem-15.erendis.dialup.pol.co.uk) left irc: "gotta go"
[19:54] Action: pedronis leaving the office
[19:54] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "ChatZilla 0.9.61 [Mozilla rv:1.7.3/20041007]"
[19:59] -lilo (lilo@levin-pdpc.staff.freenode) to $*- [Global Notice] Hi all. We're experiencing some issues with network availability due to kiddie challenge. Will keep you posted.
[20:00] mwh (~user@pc150.maths.bris.ac.uk) got netsplit.
[20:06] mwh (~user@pc150.maths.bris.ac.uk) got lost in the net-split.
----- silence for 22 minutes ----- [20:28] -lilo (lilo@levin-pdpc.staff.freenode) to $*- [Global Notice] We're doing some cleanup and at some point will allow new connects again. Thanks for your patience.
[20:43] -lilo (lilo@levin-pdpc.staff.freenode) to $*- [Global Notice] Hi folks. New connect access to the network is available intermittently. Further detail will be provided from time to time via wallops ( http://freenode.net/faq.shtml#networkinfo ) .... thanks!
[20:58] -lilo (lilo@levin-pdpc.staff.freenode) to $*- [Global Notice] Hi all. If you're running a FOSS project on freenode with economic impact, please take the time to make sure that your project and its sponsoring corporate or not-for-profit entities fill out a freenode group registration ( http://freenode.net/group_registration.shtml ). Your assistance can help us prepare economic loss estimates for law enforcement authorities when the network is attacked. Thanks.
----- silence for 21 minutes ----- [21:19] stakkars (~tismer@82.144.60.19) left irc: Read error: 110 (Connection timed out)
[21:24] _hannes (~yuuhu@i528C1802.versanet.de) joined #pypy.
----- silence for 1 hr and 51 minutes ----- [23:15] idnar (mithrandi@idnar.user) left irc: "nite all"
----- silence for 25 minutes ----- [23:40] idnar (mithrandi@idnar.user) joined #pypy.
[00:00] --- Wed Mar 16 2005