[00:13] idnar (mithrandi@idnar.user) left irc: Nick collision from services.
[00:13] idnar_ (mithrandi@idnar.user) joined #pypy.
[00:16] <stakkars> ahhaaa! Noproblem with long long literals: I can just generate unpickle statements!
[00:18] Nick change: idnar_ -> idnar
----- silence for 2 hr and 19 minutes ----- [02:37] idnar (mithrandi@idnar.user) left irc: Connection timed out
----- silence for 2 hr and 17 minutes ----- [04:54] esteban (esteban@81.60.231.91) left #pypy.
----- silence for 18 minutes ----- [05:12] stakkars (hqadcyu@dsl-62-220-11-79.berlikomm.net) left irc: Read error: 113 (No route to host)
----- silence for 2 hr and 15 minutes ----- [07:27] eikeon (~eikeon@dsl092-168-236.wdc2.dsl.speakeasy.net) left irc: Read error: 110 (Connection timed out)
----- silence for 42 minutes ----- [08:09] eikeon (~eikeon@dsl092-168-236.wdc2.dsl.speakeasy.net) joined #pypy.
----- silence for 20 minutes ----- [08:29] adim (~adim@logilab.net2.nerim.net) joined #pypy.
----- silence for 26 minutes ----- [08:55] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
----- silence for 34 minutes ----- [09:29] _hannes (mbfmry@dsl-62-220-11-79.berlikomm.net) left irc: "utz utz utz"
[09:36] arigo (~arigo@134.99.112.244) joined #pypy.
----- silence for 1 hr ----- [10:36] arigo (~arigo@134.99.112.244) left irc: "[x]chat"
----- silence for 41 minutes ----- [11:17] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.
[11:24] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "Leaving"
----- silence for 1 hr and 54 minutes ----- [13:18] mwh2 (~user@modem-223.erellont.dialup.pol.co.uk) joined #pypy.
[13:19] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
----- silence for 33 minutes ----- [13:52] mwh2 (~user@modem-223.erellont.dialup.pol.co.uk) left irc: "bye"
----- silence for 21 minutes ----- [14:13] stakkars (~tismer@82.144.60.19) joined #pypy.
[14:28] hpk (~hpk@merlinux.de) left irc: Remote closed the connection
[14:32] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.
[14:38] hpk (~hpk@merlinux.de) joined #pypy.
----- silence for 33 minutes ----- [15:11] arigo (~arigo@134.99.112.244) joined #pypy.
[15:24] fonso (~fonso@cdsev1-a1-2-125.ipcom.comunitel.net) joined #pypy.
[15:34] <cfbolz> I just managed to link the CPython API against LLVM code.
[15:34] <cfbolz> So it should be possible to implement SomeObject support in genllvm
[15:35] <arigo> ah ha
[15:35] <arigo> ChoicesOverflowError
[15:35] <cfbolz> Right
[15:36] <cfbolz> Exceptions are not supported yet in genllvm :-)
[15:36] <arigo> :-)
[15:37] <cfbolz> I would tend toward enhancing genc nonetheless.
[15:37] <arigo> that's the most immediate working path...
[15:37] <cfbolz> The problems with C are known and who knows what turns up with LLVM
[15:37] <arigo> yes, I guess we have to go at least some distance down the genc path.
[15:38] <arigo> I certainly don't want to stop you from continuing to work on genllvm, though
[15:38] <cfbolz> Oh, I won't/
[15:38] <arigo> :-)
[15:39] <cfbolz> or do you think it might make more sense working on genc at the moment?
[15:39] <arigo> no, not necessarily
[15:39] <cfbolz> Not that I know any of it yet...
[15:39] <arigo> keeping multiple paths alive is good
[15:39] <arigo> and the back-end question will come up again later when we need to go for a CPython-independent solution
[15:39] <cfbolz> Yes. I think I might even benefit from the genc-work quite a lot.
[15:40] <arigo> and vice-versa, using genllvm types and support functions should make genc's construction easier
[15:40] lac (~lac@c-51c6e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy.
[15:40] <cfbolz> Right. For example every object (dicts, lists, whatever) that gets it's own low level implementation can be shared.
[15:41] <arigo> precisely
[15:41] <arigo> I guess that will be the hard part of the upcoming genc work very soon.
[15:41] <cfbolz> Maybe
[15:42] <arigo> well, it seems that we have to do memory management "by hand" in both cases, or how do you envision it in genllvm?
[15:43] <cfbolz> yes, that's true.
[15:43] <cfbolz> for genllvm it might be worth it to implement the planned (but somehow forgotten) GC for LLVM
[15:44] <arigo> might be quite involved
[15:44] <cfbolz> true, too.
[15:44] <cfbolz> Have you any opinions whether we should do something more sophisticated than reference counting
[15:44] <cfbolz> ?
[15:44] <arigo> no...
[15:45] <arigo> if we do reference counting we will eventually need CPython's cycle detection technique
[15:45] <stakkars> hi friends. I think we should do no reference counting at all.
[15:45] <cfbolz> What to do with emulating the CPython API then
[15:46] <stakkars> just ignoring it.
[15:46] <cfbolz> I had no objections if I had to write a GC for genllvm only
[15:46] <stakkars> for C, there are simple and efficient GC implementations available, as I was told by Sam Rushing.
[15:46] <arigo> I wonder if it is possible to drop the Bohem GC in genc, but still link with CPython and use refcounting for CPython's PyObjects
[15:46] <stakkars> Will contact him about details.
[15:47] <stakkars> Boehm is even too much.
[15:47] <arigo> possibly
[15:47] <arigo> the question is if we can combine a simple GC and CPython's refcounting in the same process
[15:47] <stakkars> we don't have the problem that Boehm manages to solve.
[15:47] <cfbolz> arigo: Yeah but the Boehm GC is conservative. we could do better since genllvm can support the GC.
[15:47] <stakkars> the question is if we actually need this in the same process.
[15:48] <arigo> at first, yes
[15:49] <stakkars> we can link to CPython or use a TCP connection to attach to objects which we don't have, yet
[15:49] <arigo> well, I'm looking for ways to extend genc incrementally
[15:50] <arigo> more radical solutions involving defining a custom API to control CPython objects should come later
[15:50] <stakkars> sure.I just think that it is creating parts of its own problems.
[15:51] <cfbolz> stakkars: That's one of the benefits of genllvm :-)
[15:51] <cfbolz> (at least at the moment)
[15:52] <stakkars> cfbolz: what, exactly? Independent from CPython?
[15:52] <cfbolz> yup.
[15:52] <stakkars> arigo: I hear you, but don't see why
[15:53] <pedronis> until we have annotated most of the std object space is hard to tell how much of cpython we need
[15:53] <stakkars> just write one proxy thing and do every unimplemented type through this.
[15:54] <cfbolz> stakkars: but you have to convert all the annotated objects to and from CPython's types then
[15:56] <stakkars> cfbolz: you mean, if functions are involved that both use long and int, I would have to send the call to the server
[15:56] <stakkars> and need to convert the int to CPython?
[15:56] fonso (fonso@cdsev1-a1-2-125.ipcom.comunitel.net) left #pypy.
[15:57] <cfbolz> yes
[15:57] <stakkars> I don't think so. I would just use pickling and do RPC like calls. Unpickling is implemented and should work if the interpreter works.
[15:58] <stakkars> maybe my view is to sunny.
[15:59] <cfbolz> Hmm.
[15:59] <arigo> I'm afraid "pickling" == "lots of unforeseen problems"
[15:59] <arigo> whereas gradually adapting genc to use more types is just very safe and will work.
[16:05] <stakkars> btw, why do I still get "faking <type 'module'>"? I thought we have our own module object?
[16:06] <arigo> it's faking modules like "nt"
[16:06] <stakkars> ahh!
[16:06] <arigo> it's more convenient to fake the whole module instead of building our own Module and populating it with faked functions
[16:10] <hpk> although we might soon want to get rid of faked types completly
[16:16] <pedronis> on an unrelated note, yesterday I was bit ill but in the evening I managed to get python2.4 and pygame to work on my laptop
[16:19] <hpk> pedronis: cool (i am slightly ill too, btw)
[16:19] <pedronis> hpk: I compiled everything from source basically
[16:19] <pedronis> apart the SDL depedency
[16:19] <hpk> i am contemplating finally installig linux on the thing
[16:20] <hpk> but it probably means that i need to use an external wifi card
[16:21] <hpk> cfbolz: hello carl, i was wondering what you do in your day-to-day job?
[16:22] <cfbolz> I'm a student (math, physics, 3rd semester). But I do a bit of computer administration (40 hours/month) for the physicits.
[16:22] <hpk> i see, note that you could probably become a "partner" in the EU project which would pay you travel+accomodation to any pypy sprint
[16:23] <cfbolz> I read that on pypy-dev. What do I have to do?
[16:24] <hpk> ask us then we go off to some super-secret discussions, ask the Verfassungsschutz and such things and get back at you :-)
[16:24] <cfbolz> will you let me become a partner? please? :-)
[16:24] <hpk> :-)
[16:25] <hpk> i think that nobody has objections but i'll ask anyway and get back to you
[16:26] <cfbolz> thanks.
[16:27] <cfbolz> speaking of sprints: Disregarding the fact that I don't no whether I'll find a room I would really like to organize a sprint in Heidelberg.
[16:29] <hpk> sounds nice, heidelberg is a beautiful city
[16:30] <cfbolz> yes. I have good contacts with the main administrator of the physics institute, I'll ask him whether he has any ideas.
[16:30] <cfbolz> for a room I mean.
[16:30] <stakkars> I have absolutely no objections, but anyway I would say the regular way should be
[16:30] <stakkars> to ask the group for green light before inviting people
[16:31] <cfbolz> of course. sorry. I'll do probably do that next week.
[16:32] <stakkars> sorry, this was directed at hpk, of course :-)
[16:32] <hpk> stakkars: yes, understood, it's a bit of a chicken-and-egg problem though, but we can discuss it via mail (i just sent one)
[16:32] <cfbolz> stakkars: Oh. It could have been directed to mee too :-)
[16:32] <stakkars> fine.
[16:33] <stakkars> :-)
[16:33] <cfbolz> since we deviate from technical issues anyway: I just got a 1.0 in my linear algebra exam this morning. Hurray!
[16:33] <hpk> cfbolz: i guess july or august for a heidelberg sprint would be interesting and it's summer then
[16:34] <hpk> cfbolz: congrats!
[16:35] <cfbolz> thanks. Isn't july a bit early? I thought the Europython sprint ended in july.
[16:35] <cfbolz> august would be perfect though since there is nobody working here and it should be easier to find a good location
[16:39] lac (lac@c-51c6e055.1321-1-64736c11.cust.bredbandsbolaget.se) left #pypy.
[16:40] <adim> cfbolz: Hi
[16:40] <adim> I think Europython ends on July, 1st
[16:40] <adim> so end of August should be ok for another sprint
[16:41] <adim> (sprints were planned to be each 6 or 8 weeks I think)
[16:41] <cfbolz> End of august is probably perfect (and it's still summer then)
[16:41] <cfbolz> I'll talk to the people I have in mind on Monday
[16:41] <adim> We had also more or less talked about holding a sprint in Paris, but just "more or less"
[16:42] <cfbolz> well, the heidelberg project is "more or less" at the moment, too
[16:42] <adim> :)
[16:42] <cfbolz> :-)
[16:43] <cfbolz> I'll probably be able to say more on monday.
[16:45] <stakkars> cfbolz: congrats! I hope you can get along with the Physics. I had to change to much simpler things like Informatics after 10 Semsters :-)
[16:45] <arigo> cfbolz: yes, congrats too :-)
[16:45] arigo (~arigo@134.99.112.244) left irc: "and see you later"
[16:46] <hpk> cfbolz: august sounds fine
[16:46] <hpk> adim: how is paris in september/october? :-)
[16:47] <cfbolz> stakkars: thanks. I'm not too sure about Physics at the moment.
[16:47] <adim> hpk: I think it's still ok (just have to be before november I think)
[16:47] <adim> (purely for weather purpose of course)
[16:48] <stakkars> cfbolz: it depends of the direction of your Math studies. I was on discrete math and had to do all the complicated other stuff too for Physics
[16:48] <hpk> adim: end of september might be a good idea, this also ends our phase 1 of the EU project IIRC
[16:48] <cfbolz> stakkars: Sounds familiar. I'm into algebra and high energy physics, which doesn't match either.
[16:51] <stakkars> cfbolz: hehe, yes. This makes you study all major directions of Math, because Physics is reallyreally demanding.
[16:51] <cfbolz> stakkars: right. I'll have to decide all that in the next months and still got no idea what to do.
[16:59] <adim> Are the dates for the Europython already fixed ?
[16:59] <adim> s/Europython/Euuroptyon sprint
[17:00] <cfbolz> according to jacob in pypy-dev: 30 June - 7 July, after Europython, Göteborg, Sweden
[17:01] <adim> ok
[17:03] <hpk> in addition, i might still be going to goethenborg earlier than EuroPython to hack at least with Samuele and Armin
[17:04] <hpk> btw, has there been a call for talks already?
[17:04] <pedronis> no
[17:05] <pedronis> umph, on my machine the viewer trying to visualize the graph for all of translate_pypy is quite unusable (no response for / for example)
[17:05] <hpk> "f"?
[17:05] <pedronis> same for all commands it seems
[17:05] eikeon (~eikeon@dsl092-168-236.wdc2.dsl.speakeasy.net) left irc:
[17:06] <pedronis> it takes also forever to generate the dot graphs
[17:06] <pedronis> before visualizing something
[17:06] <pedronis> :(
[17:06] <stakkars> yeah, quite unusable on my machine, too.
[17:07] <stakkars> btw., I got almost ready with applevelinterp-ingmost applevel calls.
[17:07] <hpk> pedronis: side note, sorry that i keep confusing your surname all the time, why did you choose a different account name, anyway :-)
[17:08] <stakkars> Especially nice is stringtype: There, I *enabled* flow's immediate import feature, and it pulls all of _formatting
[17:08] <hpk> pedronis: are you using your new python2.4 installation of pygame?
[17:08] <stakkars> and _float_formatting just in, and we don't need any special treatment for those, since they are just for this.
[17:08] <stakkars> startup time has increased quite a bit, so I need to do the caching, now.
[17:08] <pedronis> hpk: it's the same with 2.3 or 2.4, and no its my work machine linux on debian
[17:09] <pedronis> but yes I had to make a package out of sources for pygame for 2.4 too, because there's no pygame for 2.4 package for debian at the moment
[17:16] <pedronis> I probably need to disable displaying the whole call graph, and have a cmd line interface to display single functions and ask what are the callers and callees of a function
[17:17] <stakkars> making this faster was one idea of Lutz, but the dot generation is still a big block.
[17:22] <pedronis> yes, if we want to display these big graphs trying to leverage OpenGL might be an idea
[17:34] <hpk> yes
[17:36] <stakkars> last time I saw him in Paris, he mentioned to me that he won't continue PyPy. But this was jet-lag. Will ask him on Monday.
[17:38] <stakkars> arrggghhh - how comes that I get problems with flowing assert statements when run under test_all?
[17:39] <stakkars> instead of exceptions.AssertionError, I suddenly get py.magic.AssertionError.
[17:41] <stakkars> why is *that* needed? A testing framework should provide something almost completely unchanged I guess.
[17:41] <pedronis> py.test is based on substituting AssertionError
[17:42] <stakkars> juck!
[17:42] <stakkars> would pretending the correct module name be hard?
[17:43] <stakkars> ok, I'll remove the explicit test for the module name... :-/
[17:46] <cfbolz> I get a Collect Error for the parser tests (test_parser.py, test_simple.py). I did a fresh checkout.
[17:46] <hpk> stakkars: pretending the "exceptions" module name would not be hard but not quite right, i think
[17:47] <hpk> it's probably better to provide an easy way to switch the special AssertionError off for specific tests
[17:47] <hpk> (you can do that with --nomagic on the command line but this switches it off for everything)
[17:47] <stakkars> I'm checking against builtin types to see what I needto generate or what the space has.
[17:48] <stakkars> this would be bad, because it happens when I'm flow-spacing the applevel calls.
[17:48] <hpk> sounds familiar :-)
[17:48] <stakkars> this would apply to allcode that tests string formatting.
[17:48] <stakkars> _formating and _float_formatting have some assert statements.
[17:49] <stakkars> ahhhh, well, these are really notmeant for testing.
[17:49] <stakkars> Is there an easy wayto disable the testing environment while I'm generating code?
[17:49] <hpk> you mean at runtime?
[17:50] <stakkars> yes. magic.enable(False) or such, because I'm bootstrapping.
[17:50] <stakkars> or in other words: The testing frameworkmight be aware of the std objspace, but avoid flow space???
[17:52] <hpk> there is "py.magic.revoke(assertion=True)" and "py.magic.invoke(assertion=True)" to switch it off/on
[17:53] <hpk> but it wouldn't work nicely if you run with --nomagic for starters
[17:53] <stakkars> yes,I just saw it. But I would need to know whether I'm debugged or not.
[17:53] <hpk> side note: at some point i would _love_ some documentation on geninterp and how it does things ...
[17:54] <stakkars> yes.It does it almost exactly like genc, andI'd love to have its doco, too.
[17:55] <hpk> so you'd like someone else to write genc doco and just point to it :-)
[17:55] <hpk> does genc have a problem with magic.AssertionErrors as well?
[17:55] <stakkars> kind of... well, interesting would be to explain where they differ.
[17:56] <stakkars> it would, probably, if you run test code which contains assert statements through genc under the framework.
[17:56] <stakkars> it relies on stuff like
[17:56] <stakkars> if issubclass(cls, Exception):
[17:56] <stakkars> if cls.__module__ == 'exceptions':
[17:56] <stakkars> # exception are defined on the space
[17:56] <stakkars> return 'space.w_%s' % cls.__name__
[17:57] <stakkars> for geninterp, the genc part is similar but renders different code.
[17:57] <stakkars> so we are using introspection for everything, which makes it hard when the environment is not original.
[17:58] <stakkars> the simplest thing would probably be:
[17:58] <stakkars> - test sys.modules for magic
[17:58] <stakkars> - switch AssertionError off
[17:58] <stakkars> - gen code
[17:58] <stakkars> - switch back on
[17:58] <hpk> "test sys.modules for magic" ?
[17:59] <stakkars> aaahh, much easier: See if __builtins__.AssertionError is the correct one and take action.
[17:59] <stakkars> yes, I thought the py.magic module would show up in the test environ?
[17:59] <hpk> yes sure, but you can't judge from that if magic is in place
[18:00] <pedronis> stakkars: you could change the cls.__module__ line to
[18:00] <stakkars> but I can check if AssertionError.__class__ is exceptions
[18:01] <pedronis> if getattr(__builtin__,cls.__name__) is cls:
[18:01] <stakkars> okok, that looks fine tome! thx
[18:05] <stakkars> YAHOOO it worrrrkkssss
[18:08] <cfbolz> bye. see you tomorrow.
[18:08] <stakkars> bye
[18:08] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "Leaving"
[18:12] _hannes (iacjfhf@dsl-62-220-11-226.berlikomm.net) joined #pypy.
[18:17] <stakkars> hey, the compiling gives quite a good speed boost!
[18:18] <stakkars> test_all with original applevel:
[18:18] <stakkars> tests finished: 835 passed, 134 skipped in 102.59 seconds
[18:18] <stakkars> test_all with applevelinterp in place almost always
[18:19] <stakkars> tests finished: 835 passed, 134 skipped in 72.55 seconds
[18:19] <stakkars> :-D
[18:19] <stakkars> I guess the win is mostly dueto flowing the normalize_exception,letme check...
[18:22] <stakkars> well, quite. removing normalize_exception gives
[18:22] <stakkars> tests finished: 835 passed, 134 skipped in 95.80
[18:24] <stakkars> checking in, going home :)
[18:27] <hpk> :-)
[18:28] adim (adim@logilab.net2.nerim.net) left #pypy.
[18:28] <stakkars> well, the remaining ones are not RPython at all.
[18:28] <stakkars> Just one which hanlessysmust get extra support.
[18:29] <stakkars> BTW., there is a failing test (labelled C), because pyparser cannot be imported.
[18:29] <jriehl> stakkars: Could you give me more details on this?
[18:29] <stakkars> well, I think the module was checked in with some path settings in place, so it worked.
[18:30] <stakkars> [D:\pypy\dist\pypy\module\parser\test\test_simple.py:6]
[18:30] <stakkars> E return old_import_hook(name, glob, loc, fromlist)
[18:30] <stakkars> ~ ImportError: << No module named pyparser
[18:30] <jriehl> Gotcha.
[18:31] <stakkars> we got alot of import hookers as it seems :-)
[18:31] <jriehl> We should most likely remove that test. It is an internal test to verify that pyparser matches the CPython parser.
[18:32] <jriehl> Conversely, we can automatically generate the tuple data for comparison each time the parser is generated.
[18:32] <jriehl> (At least w/Basil laying around.)
[18:33] <stakkars> why does the import error occour`?
[18:33] <jriehl> Lemme look.
[18:34] <stakkars> another question for everybody:
[18:34] <stakkars> applevelinterp-ing all the things takes some time. I want to spit out a single module
[18:34] <stakkars> as some cache file, which holds recompiled code.
[18:34] <stakkars> Are there any opinions about where this should be?
[18:36] <stakkars> I'm a little bit in favor of one single file for all generated code, also things like classobjinterp.
[18:36] <stakkars> The cache file will contain a dict, keyed with source code, and valued by generated init function,
[18:36] <stakkars> so this will never be false.
[18:37] <stakkars> or do we want such a thing by directory?
[18:39] <stakkars> I think a subfolder like lib/generated would be nice. Unfortunately, this cannot be imported, directly.
[18:40] <jriehl> Is test_simple.py run from CPython or Pypy?
[18:41] <stakkars> it was run by test_all, so I guess this is PyPy
[18:41] <jriehl> (I see the error you are getting in CPython, and the fix there would be to import from pypy.)
[18:41] Action: hpk has to leave soon
[18:41] <hpk> jriehl: did you see the parser discussion on pypy-dev?
[18:42] <jriehl> hpk: Yep. I'm trying to come up with a response right now.
[18:42] <jriehl> I'm just going to submit to any decision the group has, irregardless if the decision is technical and/or political.
[18:43] <hpk> we'll see
[18:43] <jriehl> I can see Logilab being a good choice because they are "local" and can work much more closely within the core.
[18:43] <hpk> you have been to more sprints than they so far :-)
[18:44] <hpk> but nevertheless probably right
[18:44] Action: hpk is out for a while
[18:44] <stakkars> hpk: before you are away
[18:44] <stakkars> wheredo I put the cache file?
[18:46] <hpk> i would guess per directory is easier
[18:47] <stakkars> in a sense, yes, but well, in case of applevelinterp, I even have a hard time to figure out where I am :-]
[18:47] <hpk> i really don't know off-hand and haven't looked into the according code yet
[18:47] mwh2 (~user@modem-153.erellont.dialup.pol.co.uk) joined #pypy.
[18:47] Action: hpk is really out now
[18:48] <stakkars> hi mike, and bye
[18:53] <mwh2> indeed
[18:53] <mwh2> i'm only popping in for a few seconds
[18:54] <stakkars> I'm leaving after skimming emails
[18:54] mwh2 (~user@modem-153.erellont.dialup.pol.co.uk) left irc: "bye"
----- silence for 20 minutes ----- [19:14] stakkars (~tismer@82.144.60.19) left irc: "bye"
[19:19] idnar (mithrandi@idnar.user) joined #pypy.
----- silence for 27 minutes ----- [19:46] Action: pedronis leaving
[19:46] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "ChatZilla 0.9.61 [Mozilla rv:1.7.6/20050324]"
----- silence for 1 hr and 4 minutes ----- [20:50] MatriXica (~Matrixica@83-97-75-249.evolva.ro) joined #pypy.
[20:50] <MatriXica> ola
[21:04] MatriXica (~Matrixica@83-97-75-249.evolva.ro) left irc:
----- silence for 59 minutes ----- [22:03] _hannes (iacjfhf@dsl-62-220-11-226.berlikomm.net) left irc: Read error: 104 (Connection reset by peer)
----- silence for 1 hr and 41 minutes ----- [23:44] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
[23:50] esteban (~esteban@DWM-91-231.go.retevision.es) joined #pypy.
[00:00] --- Fri Apr 1 2005