[00:35] pyb0t joined #pypy.
[00:41] stakkars (xwpkxd@i528C131C.versanet.de) joined #pypy.
[00:41] <stakkars> hey!
[00:42] <stakkars> it is just fine :-)
[00:43] <stakkars> I'm anyway checking in my code, because it is a single line, pluf five lines plus of comments, which is worth it.
[00:44] _hannes (pxqgza@i528C131C.versanet.de) left irc: "utz utz utz"
[00:45] <stakkars> We should note in the source, that the reason for this mess was a parser error in tcc,
[00:45] <stakkars> and that we should generate unique names, anyway.So I'm checking this simple thing in!
----- silence for 2 hr and 44 minutes ----- [03:29] stakkars (xwpkxd@i528C131C.versanet.de) left irc: Read error: 104 (Connection reset by peer)
[03:30] fredrik (fredrik@c83-248-135-181.bredband.comhem.se) left irc: "http://fredrikj.net";
----- silence for 4 hr and 21 minutes ----- [07:51] Gromit (~bear@A36cc.a.pppool.de) joined #pypy.
----- silence for 32 minutes ----- [08:23] Arafat (~bear@B74a0.b.pppool.de) joined #pypy.
----- silence for 23 minutes ----- [08:46] Gromit (~bear@A36cc.a.pppool.de) left irc: Read error: 110 (Connection timed out)
[08:48] Nick change: Arafat -> Gromit
----- silence for 43 minutes ----- [09:31] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: "This computer has gone to sleep"
----- silence for 20 minutes ----- [09:51] arigo (~arigo@134.99.112.244) joined #pypy.
----- silence for 1 hr and 1 minute ----- [10:52] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
[10:54] ludal (~ludal@logilab.net2.nerim.net) left irc: Remote closed the connection
[10:55] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
[10:56] ludal (~ludal@logilab.net2.nerim.net) left irc: Remote closed the connection
[10:57] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
----- silence for 1 hr and 7 minutes ----- [12:04] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.
[12:07] arigo (~arigo@134.99.112.244) left irc: "[x]chat"
[12:22] Arafat (~bear@A369e.a.pppool.de) joined #pypy.
[12:23] dialtone (~dialtone@host158-206.pool8252.interbusiness.it) joined #pypy.
[12:27] Gromit (~bear@B74a0.b.pppool.de) left irc: Read error: 110 (Connection timed out)
[12:32] dialtone (~dialtone@host158-206.pool8252.interbusiness.it) left irc: "This computer has gone to sleep"
[12:40] arigo (~arigo@134.99.112.244) joined #pypy.
[12:53] Nick change: Arafat -> Gromit
[12:54] arigo (~arigo@134.99.112.244) left irc: "[x]chat"
[12:58] _hannes (~yuuhu@i528C13A0.versanet.de) joined #pypy.
[13:06] Gromit (~bear@A369e.a.pppool.de) left irc: Read error: 54 (Connection reset by peer)
[13:15] Gromit (~bear@A36a2.a.pppool.de) joined #pypy.
[13:25] dialtone (~dialtone@host158-206.pool8252.interbusiness.it) joined #pypy.
[13:33] dialtone (~dialtone@host158-206.pool8252.interbusiness.it) left irc: "This computer has gone to sleep"
----- silence for 57 minutes ----- [14:30] gfunch (~chatzilla@breisfel-01.cvmbs.colostate.edu) joined #pypy.
[14:31] _hannes (~yuuhu@i528C13A0.versanet.de) left irc: "utz utz utz"
[14:38] gfunch (chatzilla@breisfel-01.cvmbs.colostate.edu) left #pypy.
----- silence for 32 minutes ----- [15:10] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[15:11] <cfbolz> hi!
[15:20] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "Leaving"
[15:29] dialtone (~dialtone@host187-0.pool21345.interbusiness.it) joined #pypy.
[15:34] dialtone (~dialtone@host187-0.pool21345.interbusiness.it) left irc: "This computer has gone to sleep"
----- silence for 50 minutes ----- [16:24] Gromit (~bear@A36a2.a.pppool.de) left irc: Read error: 104 (Connection reset by peer)
[16:24] Arafat (~bear@port1355.fra.ginko.net) joined #pypy.
[16:27] dialtone (~dialtone@host187-0.pool21345.interbusiness.it) joined #pypy.
[16:28] Nick change: Arafat -> Gromit
[16:40] arigo (~arigo@134.99.18.225) joined #pypy.
[16:47] <hpk> arigo: hey armin, preparing your talk last-minute? :-)
[16:47] <arigo> hi!
[16:48] <hpk> or was it already?
[16:48] <arigo> it was already at 1 o'clock
[16:48] <hpk> ah ok, did it go well? tell a bit!
[16:48] <hpk> (although beware google which might find the locks, so don't drop names :-)
[16:48] <arigo> well, it was originally meant just as a status update for my prof and my colleague
[16:49] <arigo> wasn't too suited to people who didn't know about Python in the first place
[16:49] <arigo> but they still got the point, I think
[16:50] <arigo> interesting to them is the fact that we have basically the first good program verification suite
[16:50] <arigo> or could have, with a bit more efforts.
[16:50] <hpk> yes
[16:51] <hpk> we should discuss the april release target soon
[16:51] <arigo> yes
[16:53] <hpk> maybe we two can work a bit on the "releasescheme.txt" both for the py lib and for pypy over the weekend
[16:53] <hpk> it'S somewhat easier sprinting on it than discussing it via IRC or email
[16:53] <hpk> how many people were there?
[16:53] <arigo> yes
[16:54] <arigo> a roomful, ~20
[16:54] <hpk> hey great!
[16:54] <hpk> that shows a lot of interest from what i remember from our universities meetings
[16:54] <arigo> I guess it's a local habit, I'd say the whole departement usually turns up at the seminars.
[16:55] <arigo> though I haven't seen any other seminar so far.
[16:55] Arafat (~bear@A368c.a.pppool.de) joined #pypy.
[16:55] Nick change: Arafat -> Gromit_
[16:55] Gromit (~bear@port1355.fra.ginko.net) left irc: Nick collision from services.
[16:55] Nick change: Gromit_ -> Gromit
[16:56] <hpk> arigo: ok, but i guess it was a good "einstand" (getting started/introduction) for you
[16:57] <arigo> i guess so.
[16:57] <hpk> arigo: sidenote, i am going to add a new namespace 'py.thread' with WorkerPool/ThreadOut classes in it
[16:57] <hpk> now is the time to object :-)
[16:58] <arigo> 'py.thread'... hum
[17:00] <hpk> do you have a better suggestion or do you doubt this should be exposed at all?
[17:01] <arigo> I'm a bit afraid that whenever you need threads, you need them in a slightly different way
[17:01] <arigo> so I don't know how useful it is to expose them at all, at this point
[17:02] <arigo> but I may be the wrong person to ask -- I never use 'threading' but always the low-level 'thread' mecanism
[17:05] <hpk> i find it useful to have well tested utilities for threading available
[17:05] <arigo> makes sense, then I'm just the wrong person to ask :-)
[17:05] <hpk> ok
[17:05] <pedronis> hpk: java has recently grown a good set of utilities for threading
[17:06] <hpk> interesting, do you have a direct pointer into the API?
[17:06] <pedronis> they are javaish of course but there's agreement that they are
[17:06] <pedronis> well designed
[17:06] <pedronis> java is very much into thread
[17:06] <pedronis> and the author is a respected expert in threading and memory models under threading etc
[17:07] <hpk> i don'T want to get down at memory models with py.thread so far :-)
[17:07] <hpk> but anyway, i am interested in more details
[17:07] <arigo> hpk: we should remove extractdict from the py lib, btw, it was just useless
[17:08] <hpk> arigo: ok, go ahead if you like
[17:08] <pedronis> hpk: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/package-summary.html
[17:08] <hpk> thanks
[17:08] <hpk> this all begins to look like c++ :-)
[17:09] <pedronis> yes, generics are that way ;)
[17:09] <pedronis> I'm very unconviced that they were a worthy addition
[17:10] <pedronis> they also make an even less suited language for teaching I think
[17:10] <pedronis> s/make/make java
[17:10] <hpk> this looks even more ugly than decorators ...
[17:10] <pedronis> well, for python you can forget about all the <...> stuff
[17:10] <pedronis> :)
[17:11] <pedronis> author's homepage is here: http://g.oswego.edu/
[17:11] <hpk> well, html/xml makes at least some sense with respect to <> :-)
[17:12] <pedronis> http://gee.cs.oswego.edu/dl/concurrency-interest/index.html should have more links about the API
[17:13] <pedronis> hpk: orthogonally to the generics, is really judged a good set of utilities, it is worth a cursory look
[17:14] <pedronis> arigo: as you know I'm working on targetpypy annotation
[17:15] <pedronis> I'm wondering what to do about tool.uid.fixid
[17:16] Gromit (~bear@A368c.a.pppool.de) left irc: Read error: 110 (Connection timed out)
[17:16] <arigo> hpk: checked in successfully, but now Could not open the requested SVN filesystem
[17:17] <arigo> pedronis: special-case it to return r_uint, probably?
[17:17] <hpk> hum, fixed now,
[17:17] <pedronis> arigo: well for that we could use r_uint instead directly
[17:17] <arigo> of course there is the question of how to handle machines where sizeof(void*) > sizeof(long)
[17:17] <pedronis> arigo: yes, that's my question
[17:18] Gromit (~bear@B7498.b.pppool.de) joined #pypy.
[17:18] <arigo> hpk: a py lib test is failing because the tool/ directory isn't a package (missing __init__.py)
[17:18] <pedronis> arigo: do we bother introducing r_huint
[17:18] <pedronis> h stands for huge
[17:18] <arigo> huge unsigned int? :-)
[17:18] <pedronis> it would us a mask as such calculated for fixid
[17:18] <pedronis> s/us/use
[17:19] <arigo> space.wrap(r_huint(x)) would return a long object?
[17:20] <pedronis> probably, but the question is whether to bother now or later
[17:21] <arigo> XXX later, I guess
[17:21] <pedronis> ok
[17:21] <pedronis> I will substitute the one use of fixid with r_uint and XXX appropriately
[17:24] <arigo> hum, it's at a place doing a %x string formatting at interp-level
[17:24] <arigo> it raises the question of how much of string formatting we'll support ultimately
[17:25] <pedronis> yes
[17:25] <pedronis> well I found also a place where we do "...".split at interp level
[17:26] <arigo> hum
[17:27] <arigo> is that in import logic, by any change ?
[17:27] <pedronis> maybe there's one there too, but no this one was in stringobject itself
[17:27] <arigo> argh.
[17:27] <pedronis> and I left it for now
[17:28] <pedronis> because I'm chasing SomeObjects at the moment
[17:28] <arigo> :-)
[17:29] <pedronis> well, translate_pypy.py targetpypy annotation phase now finish but with 14 blocked blocks and a ton of degenerated to SomeObjects
[17:29] <arigo> :-(
[17:30] <pedronis> well, some issues are shallow
[17:31] <pedronis> but of course SomeObjects propagates so it's a slow work to fix that
[17:31] <pedronis> one source for example was newtuple
[17:31] <pedronis> because assert isinstance(., list) was not being helpful at all
[17:31] <arigo> I saw that log, yes
[17:32] <pedronis> on the contrary it was doing SomeList(SomeInst(W_Root)) -> SomeList(SomeObject())
[17:32] <pedronis> very bad
[17:32] <arigo> I think the type_of logic is incomplete,
[17:32] <arigo> it should not *replace* the existing annotation
[17:33] <arigo> but do the intersection, somehow
[17:33] <pedronis> but there's a check to prevent degrading things but it doesn't work with factories
[17:33] <arigo> argh I see
[17:33] <arigo> it's probably soon time to remove factory.py altogether
[17:34] <pedronis> contains and factories together are a bit broken
[17:34] <arigo> yes
[17:34] <pedronis> anyway the logic in isinstance was creating a factory-less list which right now is a bad idea in itself
[17:34] <arigo> indeed
[17:43] <arigo> pedronis: ok if I try to remove factory.py now?
[17:43] <pedronis> arigo: but you still need to attach the creation location to lists
[17:43] <pedronis> do distinguish them
[17:43] <pedronis> to distinguish tehm
[17:43] <arigo> yes, I was thinking about a ListDef and a DictDef similar to ClassDef
[17:44] <arigo> but attached by position_key
[17:45] <pedronis> but then you need a set of position_keys for union
[17:45] <arigo> unions would merge the ListDefs, I guess, then all position_keys point to the same one
[17:46] <pedronis> I'm thinking what to do when you unify to lists from different position_keys
[17:46] <arigo> there are two solutions, we can keep the original list separately annotatable or not
[17:47] <arigo> but at first, code generators won't be happy at all with lists that change their content set at run-time
[17:51] <pedronis> so SomeList would point to a ListDef
[17:51] <arigo> yes
[17:51] <pedronis> and there would be a position_key -> ListDef mapping
[17:51] <arigo> yes
[17:51] <pedronis> wich means you still reflow both from reading and creating points
[17:51] <arigo> from reading points only
[17:51] <arigo> I think
[17:52] <pedronis> no, you cannot reflow just from reading points
[17:53] <pedronis> at most you could not reflow at all
[17:53] <arigo> yes, that's possible, but then it would be correct, no?
[17:53] <pedronis> if I understand union of SomeList(ListDef1) SomeList(ListDef2) will create a ListDef3
[17:54] <arigo> ah, I see
[17:54] <pedronis> you can just let that propagate
[17:54] <arigo> instead, what we'd like is that "ListDef1 is ListDef2" should suddenly be true
[17:55] <pedronis> I see, that would solve the creation points problem
[17:55] <arigo> we might get away with a custom __eq__ operator that makes listdefs suddenly equal
[17:56] <pedronis> I see, but that's always a risky proposition
[17:56] <pedronis> I think at some point we had code like that
[17:56] <pedronis> tweaking with identities
[17:56] <pedronis> and it got messy
[17:58] <arigo> well we can always do the redirection explicitely
[17:58] <arigo> i.e. make ListDef1.become = ListDef2.become = ListDef3
[17:58] <arigo> and then all reads of ListDef1.getvalue() would be deferred to ListDef3.getvalue()
[17:59] <arigo> so we'd have SomeList that still use ListDef1 at some point, but it's not a problem
[18:00] <pedronis> or always use a level of indirection
[18:01] <pedronis> that means SomeList carry something that point to a ListDef
[18:02] Gromit (~bear@B7498.b.pppool.de) left irc: Read error: 60 (Operation timed out)
[18:02] <arigo> hum, there is a problem with the union, still
[18:02] <arigo> if we want unionof(two lists) to contain each of the original list
[18:03] <arigo> well, it hasn't been true so far with the existing SomeList
[18:03] <arigo> but that's not a reason
[18:03] <arigo> er?
[18:03] <arigo> no I'm talking 100% nonsense
[18:04] <pedronis> at least I didn
[18:04] <pedronis> t understand the last bits
[18:05] <arigo> ah yes, another note: for the disabled test of recursive lists,
[18:05] <arigo> actually, to make it work, one way would be:
[18:05] <arigo> take the model where SomeList points to something pointing to ListDef
[18:05] <arigo> but then there is a one-to-one correspondance between SomeLists and ListDefs
[18:06] <arigo> hence we can make SomeList point to something which points back to SomeList
[18:06] <arigo> i.e. SomeList points to a something that tells "here is the generalized version of yourself"
[18:07] <arigo> the purpose of this is to have a SomeList available to the intermediate object,
[18:07] <arigo> so that recursive lists can use themselves indirectly as their own elements
[18:08] <arigo> (am I making any sense at all?=
[18:08] <arigo> )
[18:08] <pedronis> you can have SomeList = sl -> something -> ListDef -> sl
[18:09] <arigo> yes, I'm just trying to hack the ListDef away :-)
[18:09] <arigo> but ok, that might not make much sense
[18:11] <pedronis> well, the thing is that something can compare but the just comparing its pointed to ListDef identity
[18:11] <pedronis> s/but/by
[18:11] <arigo> makes sense
[18:12] <pedronis> which makes SomeList immutable but the comparison still sane, at least as sane as the current SomeInstance one
[18:12] <arigo> :-)
[18:13] <arigo> not sure I remember why we need ListDef, instead of just updating the fields of the 'something' object
[18:14] <arigo> ah yes
[18:14] <arigo> ok
[18:14] <arigo> hum no (arigo lost)
[18:15] <pedronis> because by union you would need to rember the other something object unified in the past
[18:15] <pedronis> and change them too
[18:16] <arigo> yes, so the 'something' objects would point to all the other 'something' objects they have been unified with
[18:16] <arigo> and change them all
[18:19] <pedronis> at this point I'm wondering whether instead of keeping a point inside somelist
[18:19] <pedronis> keeping a mapping somelist -> info would be saner
[18:19] <pedronis> like I'm doing for the PBCs
[18:20] <arigo> well you need to store something on the SomeList, for comparison and contains
[18:20] <arigo> btw, SomeObject is supposed to be not hashable
[18:20] <arigo> it has an __eq__ and no __hash__
[18:21] <pedronis> I see, that's a detail
[18:21] <pedronis> anyway I'm thinking somelist -> (union of somelists, info)
[18:21] <pedronis> linke for the PBCs
[18:22] <pedronis> and comparison would retrieve the info and compare by that indentity
[18:23] <arigo> tweak SomeList.__eq__ ?
[18:23] <pedronis> yes, but the mapping itself would probaly use the SomeList id
[18:23] <pedronis> not SomeList directly
[18:23] <pedronis> and then creation point would always reuse the somelist
[18:24] <pedronis> the same somelist
[18:24] <arigo> looks more complicated than necessary
[18:24] <pedronis> maybe
[18:24] <arigo> SomeObjects are meant to be immutable values not to be compared by id
[18:26] <pedronis> well, the problem is that when we unify somelists we want anything that was unified also in the past updated too
[18:27] <arigo> we need sets of things that have been unified
[18:31] <pedronis> that's the something
[18:31] <arigo> after some playing around, I suggest to rename 'something' to ListDef and 'ListDef' to ListItem
[18:31] <arigo> a ListDef, like a ClassDef, would then point to the info about its "attribute", the ListItem
[18:32] <arigo> the ListItem has an s_value, read_locations, and itemof mapping back to the ListDefs that use it
[18:33] <pedronis> so when you merge ListItems you update all the ListDefs it points too
[18:33] <pedronis> s/too/to
[18:34] <arigo> yes
[18:36] <pedronis> that would work, the question is a bit the cost of all the backupdating
[18:36] <arigo> it shouldn't be too common to have lots of lists merging
[18:37] <arigo> merging should reflow, as it generalize the value of one or both lists, right=
[18:37] <arigo> ?
[18:38] <pedronis> it should reflow from reading points yes
[18:38] <arigo> ok
[18:38] <pedronis> one messy issue is there are many way to read from a list
[18:38] <arigo> yes
[18:39] <pedronis> all places dispatching on SomeList or .s_item should be checked
[18:39] <pedronis> or using .s_item
[18:40] <arigo> yup
[18:41] <pedronis> you also need a mapping creation point -> ListDef
[18:41] <arigo> yes
[18:41] <pedronis> to reuse the ListDef
[18:41] <arigo> do I need to reuse the ListDef in valueoftype(list) ?
[18:42] <arigo> ah, I can just return always the same most-general ListDef, anyway
[18:42] <pedronis> yes
[18:42] <pedronis> also with union you can return one of the ListDef
[18:43] <arigo> yes, any one of the two existing ListDefs
[18:44] <arigo> then I start it all again with SomeDict :-)
[18:45] <pedronis> umph, of course we have string slicing used too
[18:45] <arigo> yes, that's hard to avoid, I guess
[18:46] <pedronis> well, I'm discovering all of this stuff
[18:46] <arigo> :-|
[18:47] <pedronis> because str_w__String is degenerating to SomeObject
[18:47] <pedronis> because W_StringObjects are constructed with SomeObject as _value by some of the operations we don't have annotate support
[18:52] <arigo> hard to track down
[18:52] <arigo> maybe we need a sanity test file that says that some attributes of some classes shouldn't be more general than some annotation
[18:52] <arigo> then the annotator would complain at the moment they become more general
[18:57] <pedronis> yes
[19:03] gfunch (~chatzilla@breisfel-01.cvmbs.colostate.edu) joined #pypy.
[19:11] gfunch (chatzilla@breisfel-01.cvmbs.colostate.edu) left #pypy.
[19:19] <arigo> there are not too many .s_item access, apart from (argh) in the test
[19:20] <pedronis> I see
[19:20] <pedronis> I discovered anotether fun problem in stringobject, it was reusing the same list for strings and W_StringObjects
[19:22] <arigo> :-|
[19:29] Action: arigo checks in ListDefs
[19:44] <pedronis> arigo: the ListDef repr needs improvement :)
[19:44] <arigo> oh
[19:46] <pedronis> I see there isn't one
[19:49] <pedronis> arigo: should I write one?
[19:49] <arigo> pedronis: yes, ok
[19:50] <arigo> I'm about to check in dictdef.py and related fixes, but it shouldn't conflict
[19:51] <arigo> or at least it should merge cleanly (I slightly changed class ListItem to reuse it from dictdef.py)
[19:54] dialtone (~dialtone@host187-0.pool21345.interbusiness.it) left irc: "This computer has gone to sleep"
[19:54] <arigo> pedronis: do you have a test for the "if obj2.const != list" hack about 'is_type_of' ?
[19:54] <arigo> because it shouldn't be needed any more, so I'd like to make sure there is a test that still passes
[19:54] <pedronis> yes, there are tests test_assert_list_doesnt_lose_info or something like that
[19:55] <arigo> ok :-)
[20:00] <arigo> hum, I have to fix something for it to work
[20:00] <arigo> s_list1.contains(s_list2)
[20:00] <arigo> actually computes the union, so actually merges the two lists, and always return True
[20:00] <arigo> and the lists are merged, which is bad bad bad
[20:01] <pedronis> YES
[20:01] <arigo> I guess we need a custom contains() on SomeList and SomeDict
[20:02] <arigo> there's already a custom __eq__ so I can't object to that any more :-)
[20:03] <pedronis> that's not so simple
[20:03] <pedronis> because a list can be contained in something else
[20:03] <arigo> yes, but the something else won't try to merge
[20:03] ludal (~ludal@logilab.net2.nerim.net) left irc: "Download Gaim: http://gaim.sourceforge.net/";
[20:04] <pedronis> its union may
[20:04] <arigo> hum
[20:04] <pedronis> used by the generic contains
[20:05] <arigo> unlikely, but I see the point
[20:06] <pedronis> seems dangerous to just count on the unlikely
[20:06] <arigo> then what about the generic contains() calling a method softunion(), or something less aggressive than union() ?
[20:07] <pedronis> the problem is that union was not meant to have permanent side-effects
[20:10] <arigo> the union of SomeList can be made less aggressive, it would still be valid
[20:10] <arigo> in the sense of annotating correctly
[20:11] <pedronis> but then generators would have problems
[20:11] <arigo> yes
[20:11] <arigo> I'm thinking about an intermediate solution
[20:11] <arigo> where just the valueoftype(list) is "soft"
[20:12] <arigo> the MOST_GENERAL_LISTDEF, in other words
[20:12] <arigo> which fits nicely because MOST_GENERAL_LISTDEF.bookkeeper is None, unlike the other "real" ListDefs
[20:13] <arigo> so we can say that union is aggressive only if the "bookkeeper" attributes match, which makes _some_ sense...
[20:19] <pedronis> mmh, I'm having some problems with list(())
[20:20] <arigo> ah?
[20:21] <pedronis> I'm getting it annotated as list of SomeObject instead of SomeImpValue
[20:21] <arigo> strange
[20:21] <pedronis> maybe I'm wrong
[20:21] <pedronis> I will write some tests
[20:22] <pedronis> anyway we have a lot of code depending on list(tuple) doing the right thing
[20:22] <arigo> ah ha
[20:22] <pedronis> related to switching beetween the various flavors of space.call_*
[20:22] <arigo> oh I see
[20:22] <arigo> but then how is the *arg annotated?
[20:23] <pedronis> in the case I was looking as an empty tuple
[20:23] <pedronis> SomeTuple(const=(),items=())
[20:25] <pedronis> although maybe I'm wrong
[20:25] <pedronis> and something downstream was polluting the list
[20:27] <arigo> Yay! Now circular (i.e. recursive) lists can be properly annotated.
[20:28] <arigo> going to lunch now...
[20:28] Action: arigo -> dinner, actually
[20:30] <pedronis> ok
[20:30] <pedronis> there's really a problem with list(Tuple)
----- silence for 17 minutes ----- [20:47] <pedronis> no, it works fine
[20:47] <pedronis> so it's something like
----- silence for 1 hr and 8 minutes ----- [21:55] Action: pedronis leaving
[21:55] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "Chatzilla 0.9.67 [Firefox 1.0.2/20050325]"
[22:04] arigo (~arigo@134.99.18.225) left irc: "[x]chat"
[22:10] jeroenh (~Neelix@doc.je-ju.net) joined #pypy.
[22:11] jeroenh (Neelix@doc.je-ju.net) left #pypy.
[22:23] bbiow (bbiow@82.145.232.60) joined #pypy.
[22:26] Action: bbiow slaps bbiow around a bit with a TCL powered popup
[22:26] bbiow (bbiow@82.145.232.60) left irc: Client Quit
[22:32] pedronis (~Samuele_P@c-358b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[00:00] --- Sat Apr 16 2005