[00:00] <pedronis> lac: yes
[00:48] _hannes (rrpnpf@i3ED6B20D.versanet.de) left irc: "utz utz utz"
[00:50] lac (lac@lac.silver.supporter.pdpc) left #pypy.
----- silence for 1 hr and 18 minutes ----- [02:08] 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 1 hr and 9 minutes ----- [03:17] Continuity (~kittish@host81-153-48-22.range81-153.btcentralplus.com) left irc: Read error: 60 (Operation timed out)
----- silence for 3 hr and 54 minutes ----- [07:11] idnar (mithrandi@idnar.user) left irc: Read error: 60 (Operation timed out)
----- silence for 1 hr and 13 minutes ----- [08:24] idnar (mithy@idnar.user) joined #pypy.
----- silence for 1 hr and 19 minutes ----- [09:43] stakkars (~tismer@82.144.60.19) joined #pypy.
----- silence for 2 hr and 5 minutes ----- [11:48] <stakkars> hi all
[11:48] <stakkars> when recreating exceptionsinterp, I get
[11:48] <stakkars> File "D:\pypy\dist\pypy\module\exceptionsinterp.py", line 1048, in initexceptions
[11:48] <stakkars> m.gcls_Exception = space.call(space.w_classobj, _args)
[11:48] <stakkars> AttributeError: 'StdObjSpace' object has no attribute 'w_classobj'
[11:50] <stakkars> I thought we made oldstyle classes built in, already?
[11:53] <stakkars> this is strange, since it *has* a w_classobj, if I revert to the older exceptions version.
[11:54] arigo (~arigo@vicky.ecs.soton.ac.uk) joined #pypy.
[11:56] <stakkars> hi Armin!
[11:57] <stakkars> I just built support for your new objects and stumbled over asmall problem:
[11:58] <stakkars> when I now regenerate exceptions, they use space.w_classobj
[11:58] <stakkars> this crashes, before this happens before old style classes are installed.
[11:59] <stakkars> I think this happens because I now have support for new-styles and old-style classes, and by this the exceptions become old-style.
[11:59] <arigo> that's a question for Samuele
[12:00] <stakkars> What was our decision: should I make them new-style by default? (I gues this was so before we became explicit)
[12:01] <arigo> why are they old-style at all?
[12:01] <stakkars> ok, I fall back to the existing default.
[12:01] <arigo> if we run _exceptions.py in PyPy, we should get new-style classes
[12:01] <stakkars> because they don't claim to be new-style
[12:01] <arigo> I don't see how old-style classes sneak in.
[12:01] <arigo> class X: pass
[12:01] <stakkars> old-style
[12:01] <arigo> should create new-style classes in PyPy.
[12:01] <stakkars> ?????
[12:02] <arigo> unless you change the default metaclass with the command-line argument
[12:02] <arigo> just try it interactively
[12:02] <stakkars> arghh, how shall I figure that out with geninterplevel?
[12:02] <stakkars> then I need this cmd-arg as well.
[12:03] <arigo> why?
[12:03] <arigo> we *want* new-style classes
[12:04] <stakkars> I think I missed this. I assumed it would be as usual: you get what you ask for.
[12:04] <arigo> as far as I'm concerned geninterplevel doesn't have to know anything about old-style classes, I guess
[12:04] <stakkars> And afterwe had old-style support ready, I simply assumed this would be so :-)
[12:05] <stakkars> if you give it an old-style class, it will generate one.
[12:05] <arigo> in a sense the old-/new-style distinction is not relevant to RPython code (app- or interp-level RPython)
[12:11] <stakkars> you mean, if I call space.w_classobj, this might either be old or new-style?
[12:11] <arigo> no
[12:11] <arigo> I mean don't use space.w_classobj.
[12:11] <stakkars> what else should I use?
[12:11] <arigo> well, space.w_type
[12:12] <stakkars> that was changed in genc.py, so I changed it as well :(
[12:12] <arigo> create a type that looks like the incoming app-level class, without worrying if it was old- or new-style originally.
[12:12] <stakkars> I think. Let me see.
[12:12] <arigo> ah, I see
[12:13] <arigo> genc.py is a bit different because it has to create exactly the same objects as in the original
[12:13] <arigo> e.g. there is support for all 4 descriptor types of CPython, etc.
[12:13] <stakkars> yes, and for some dumb reason I replicated this all, although not necessary...
[12:14] <arigo> it was changed in genc.py because we had to create old-style exception classes, otherwise we couldn't use the classes as exceptions when our code is loaded as a CPython ext mod...
[12:15] <stakkars> gahh. And I'm supposedto unify all this. oh-oh
[12:16] <stakkars> I still have this code in geninterplevel, which stems from genc, but now is really doing the wrong thing:
[12:16] <stakkars> # For the moment, use old-style classes exactly when the
[12:16] <stakkars> # pypy source uses old-style classes, to avoid strange problems.
[12:16] <stakkars> if not isinstance(cls, type):
[12:16] <stakkars> assert type(cls) is type(Exception)
[12:16] <stakkars> metaclass = 'space.w_classobj'
[12:17] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[12:17] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Client Quit
[12:17] <stakkars> do I simplycomment ths metaclass statement out?
[12:17] <arigo> I guess so.
[12:25] <stakkars> ok, works. Checked in. I'm now regenerating the goal, to see the difference.
[12:28] <stakkars> the new version still prints 42.
[12:28] <arigo> nice
[12:28] <arigo> off-topic:
[12:29] <arigo> I'm looking for a portable emulator for PC or for any other Linux-supporting architecture
[12:30] <arigo> I want to run (slowly is OK) a virtual machine that can be snapshotted and reloaded on a different host
[12:30] <arigo> I guess there is Stackless for Python :-)
[12:30] <stakkars> olf C file size = 17469263
[12:30] <arigo> but Python doesn't run Linux (yet?)
[12:31] <stakkars> new C file size = 17293611
[12:31] <stakkars> not *that* huge difference, but well.
[12:32] <stakkars> you don't want to run a PC in a VMWare virtualmachine on your old laptop, right? :-)
[12:34] <arigo> not necessarily VMWare no
[12:34] <arigo> I don't mind about performance
[12:34] <arigo> I mind about shapsnots reloadable on different hosts :-)
[12:35] <arigo> and eating more memory than my old laptop has isn't necessarily a problem.
[12:37] <arigo> emulating lots of stuff isn't needed, as long as it emulates network (or maybe just serial ports for PPP)
[12:37] <stakkars> VMware would be nice because you can use hard disk deltas which you pass around.
[12:38] <arigo> yes, passing diffs around is the idea, but I can make the diffs with external tools too
[12:38] <arigo> but diffs of the whole state, not just disks
[12:38] <stakkars> what exactly do you need to snapshot, whole machine as it is running?
[12:38] <stakkars> the machine state *is* the disk with VMWare. YOu hit a freeze button.
[12:38] <arigo> (the emulator doesn't even have to have disks if I can boot it off network :-)
[12:39] <arigo> ok
[12:40] <stakkars> diffing to see the code changes with the new specialization...
[12:45] <stakkars> ok, I can see that the goto variables vanished. But not much more, this is too huuuuge
[12:46] <arigo> :-)
[12:46] <stakkars> will move it to the pc and use winmerge, which is doing a better job than diff in a shell.
----- silence for 18 minutes ----- [13:04] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[13:07] <stakkars> chomps like hell on the 17 MB files...
[13:10] <stakkars> no, it still makes no sense to compare. There are too many differences. I need to introduce local temp names,or things differ way too rapidly.
[13:11] <stakkars> saving 170KB isn't that bad. I just wonder where the other 17 MB are for :-)
[13:16] <pedronis> hi
[13:16] <pedronis> stakkars: btw, setup exceptions is called before even the dummy old style classes are attached to the space
[13:17] <pedronis> also we still have your code that set call to mean make a new-style type object
[13:17] <pedronis> before running the exceptions setup code
[13:18] <pedronis> Anyway setting up exceptions to be old-style would require a more involved bootstrap coreography
[13:18] <pedronis> you need some of the exceptions to define old-style classes
[13:18] <pedronis> you can fake them temporarely but then
[13:19] <pedronis> you need to solve the issue that the old-stlyle class def code is going to capture these
[13:23] Nick change: pedronis -> pedronis_lunch
[13:30] <stakkars> pedronis: oh well, I remember. Will try to clean up there a little, too. But in a sense, this says that exceptions *have* to be new-style, and I should put that in exceptions.py as metaclass, otherwise this will break.
----- silence for 52 minutes ----- [14:22] idnar (mithy@idnar.user) left irc: "kbye"
[14:25] Nick change: pedronis_lunch -> pedronis
----- silence for 16 minutes ----- [14:41] stakkars (~tismer@82.144.60.19) left irc: Read error: 110 (Connection timed out)
[14:45] stakkars (~tismer@82.144.60.19) joined #pypy.
----- silence for 22 minutes ----- [15:07] <pedronis> btw, we had an assertion about multiple inheritance not being supported
[15:07] <pedronis> but the paranthesis were wrong
[15:07] <pedronis> so it was never triggered
[15:16] <arigo> argh
[15:16] <mwh> argh
[15:18] <pedronis> it was assert (...,...) # on multiple lines
[15:19] <arigo> I see
[15:30] <pedronis> ok, now it triggers
[15:31] <pedronis> the question is what to do about this
[15:33] <arigo> in genwaht.py ?
[15:33] <arigo> genwhat.py ?
[15:33] <pedronis> well, the issue is also for the annotator
[15:36] <pedronis> but yes one aspect of it is that for some targets multiple inheritance is not natural
[15:37] <arigo> on which classes does this assertion trigger?
[15:37] <pedronis> frames impls
[15:37] <arigo> oh
[15:38] <pedronis> we use the enhanceclass trick
[15:38] <pedronis> GeneratorFrame is a mixin
[15:39] <pedronis> so we have PyInterpFrame
[15:39] <pedronis> or PyInterpFrame+PyNestedScopeFrame
[15:39] <pedronis> or PInterpFrame+GeneratorFrame
[15:39] <pedronis> or
[15:39] <pedronis> PyInterpFrame+PyNestedScopeFrame+GeneratorFrame
[15:39] <arigo> PyInterpFrame == PyFrame, you mean?
[15:40] <pedronis> no
[15:40] <pedronis> PyInterpFrame is a subclass of PyFrame
[15:40] <arigo> ah right
[15:43] <arigo> looks like we are really using multiple inheritance here
[15:43] <pedronis> but PyNestedScopeFrame subclasses PyInterpFrame
[15:43] <pedronis> and GenetatorFrame could be concretely mixed in
[15:43] <arigo> makes sense
[15:44] <pedronis> but the general question
[15:44] <pedronis> is whether we want to support multiple inheritance in the generators
[15:44] <arigo> probably not
[15:44] <pedronis> I agree
[15:45] <pedronis> the complexity
[15:45] <pedronis> doesn't buy as much
[15:45] <arigo> GeneratorFrame is not really a mixin...
[15:45] <arigo> because of the 'exhausted' attribute
[15:45] <arigo> which is used by the GeneratorIterator class
[15:46] <pedronis> I see
[15:46] <pedronis> messy issue
[15:46] <arigo> if we just copy all methods of GeneratorFrame into a new subclass of PyNestedScopeFrame,
[15:46] <arigo> then exhausted would be raised to the base Frame class :-(
[15:47] <pedronis> probably PyInterpFrame
[15:47] <pedronis> that's going to be the common class
[15:48] <arigo> yes, because in our case all classes above PyInterpFrame are abstract anyway
[15:49] <pedronis> well, we have model similar to java
[15:49] <pedronis> but we don't really have interfaces
[15:49] <pedronis> at best we can put an abstract isexhausted into PyInterpFrame
[15:49] <arigo> messy
[15:50] <arigo> btw
[15:50] <arigo> I think that generator.py can be slightly rewritten
[15:50] <arigo> now that we simplified the next() operation and got rid of that NoValue exception a long time ago
[15:51] <arigo> I think exhausted can be moved away from GeneratorFrame
[15:51] <arigo> that would make sense anyway.
[15:53] <arigo> lines 62-63 don't really make sense, too
[15:56] <pedronis> so we move exhausted to the iterator
[15:56] <arigo> yes.
[15:57] <arigo> did the change, running the tests...
[15:59] <arigo> so now GeneratorFrame is a mixin
[15:59] <pedronis> ok
[16:00] <arigo> a few more hacks in pycode.py will get rid of this particular multiple inheritance.
[16:01] <pedronis> well we don't really need enhanceclass for PyNestedScopeFrame
[16:01] <pedronis> and we can construct concrete subclasses resusing just GeneratorFrame dict
[16:02] <arigo> yes, and we can even do it "by hand" instead of writing a general mixin system :-)
----- silence for 29 minutes ----- [16:31] <pedronis> # hack! it is useful to have UNDEFINED be an instance of Constant too.
[16:31] <pedronis> # PyFrame then automatically uses this Constant as a marker for
[16:31] <pedronis> # non-initialized variables.
[16:31] <pedronis> from pypy.interpreter.eval import UNDEFINED
[16:31] <pedronis> UndefinedConstant = UNDEFINED.__class__
[16:31] <pedronis> UndefinedConstant.__bases__ += (Constant,)
[16:31] <pedronis> Constant.__init__(UNDEFINED, None)
[16:34] Action: arigo whistles
[16:35] <pedronis> umph
[16:36] <pedronis> although here we have also the problem that UNDEFINED should subclass at least W_Root and not simply object
[16:36] <pedronis> of course this just needs to special cased somehow
[16:37] <arigo> we should probably replace UNDEFINED with None now
[16:37] <arigo> at some point we feared 'None' could be a wrapped object for some space
[16:37] <arigo> now it has been degreed illegal.
[16:38] <pedronis> I see
[16:38] <arigo> if we do this then we force ourselves to find a clean solution to the #hack! above.
[16:44] <pedronis> there just one reference to UNDEFINED in the flow space
[16:48] <arigo> but if UNDEFINED isn't a Constant, then we need a few more (probably in framestate.py only, though)
----- silence for 26 minutes ----- [17:14] <pedronis> arigo: I see, I tried making it None
[17:14] <pedronis> flow should then deal with Constant/Variable or None
[17:21] <pedronis> arigo, stakkars: btw, is test_geninterp passing for you?
[17:36] <stakkars> eeek! Since it worked with exceptions/_classobj, I forgot this one, which raises a py.path problem that I introduced ;-)
[17:45] <stakkars> even worse. py.path has problems itself because it does not cope with its own tricks about source paths...
[17:45] <stakkars> geninterp has a problem creating instances, now, after I changed metaclass behavior.
[17:48] <arigo> pedronis: Constant/Variable or None:
[17:48] <arigo> actually it can be done more cleanly
[17:49] <arigo> FrameState.__init__ can look for None in the return value of getfastscope()
[17:50] <arigo> and change them into Constant(UNDEFINED) itself
[17:50] <arigo> where UNDEFINED is some local singleton.
[17:50] <arigo> restoreframe() would do the reverse operation
[17:50] <arigo> and then the rest of the flow objspace doesn't care about None
[17:51] <arigo> the role of FrameState.__init__()/restoreframe() is precisely to convert
[17:51] <arigo> between Frame state and a flat list of Constant/Variables
[17:53] _hannes (xrkxext@i3ED6B1A4.versanet.de) joined #pypy.
[17:57] hpk (~hpk@mail.trillke.de) left irc: Remote closed the connection
[18:04] <stakkars> pedronis, arigo: now I understand why genc.py generates this as a runtime-check:
[18:04] <stakkars> self.initcode.append('if isinstance(%s, type):' % cls)
[18:05] <stakkars> I have to do the same :(
[18:05] <arigo> ?
[18:05] <pedronis> don't support old-style classes
[18:07] <stakkars> not at all? No, I need to figure out what I have at runtimeof the generated code, and then create a class instance using space.w_instance, and then EEEEK
[18:07] <stakkars> again: if I have an instance of something, what is the correct way to build it for geninterp?
[18:08] <arigo> don't support old-style classes at all
[18:09] <arigo> if you have an instance it's probably of a class that you translated too
[18:09] <arigo> and when you translate a class, make it new-style always.
[18:10] <arigo> hum
[18:10] <stakkars> sure, it is. Why make it new-style? I thought this is not in my hands, and I should obey what pypy does?
[18:10] <arigo> no, I see your point
[18:10] <stakkars> so I have something that I created, no idea what it is, and I need to create an instance, but how.
[18:11] <arigo> if you need an instance of something that you created then it must be new-style
[18:11] <arigo> but it's possible that you need an instance of something else
[18:12] <stakkars> And since I have no pypy running, but my module is used later by some code, I must allow for old and new style in a way.
[18:12] <arigo> I'm lost now
[18:12] <stakkars> see snippets.py, for instance() :-)
[18:13] <stakkars> there is some class Z created.No idea if old or new style, but I have to create it.
[18:13] <arigo> that's easy: make it new style always
[18:13] <stakkars> Later on, I have to create an instance which is an instance of this class Z
[18:13] <arigo> if you run snippet.py in PyPy, all the classes will be new-style always.
[18:14] <stakkars> well, for classes, I call space.w_type, assuming that the space will know what to do.
[18:14] <stakkars> ahh, I see.
[18:14] <stakkars> that means I use w_type, grab the meta class and so on and that's it?
[18:15] <arigo> don't worry about the meta class, either
[18:15] <arigo> don't copy what genc.py does, here
[18:15] <arigo> only keep what you did before copying this!
[18:15] <arigo> :-)
[18:16] <arigo> just call space.w_type, as the way of creating (all) classes
[18:16] <stakkars> must go back in history to figure that out. I can't remember how I faked instances at all :-/
[18:21] <pedronis> arigo: I changed UNDEFINED to None, and fixed the flow space
[18:21] <pedronis> I' running some more tests
[18:21] <pedronis> then I check it in
----- silence for 25 minutes ----- [18:46] <stakkars> arigo: ok, I trashed the old-style stuff and rewrote things. My older code was much worse.
[18:46] <stakkars> I see you fiddling with __reduce__ex and such, which I probably have to do as well :-]
[18:48] <arigo> no no
[18:48] <arigo> (that's samuele fiddling, not me :-)
[18:49] <arigo> but that's to build instances of strange new-style classes
[18:49] <arigo> in your case you only have simple ones
[18:49] <arigo> (just stop looking at genc.py and do the instance construction "naively")
[18:50] <arigo> i.e. %s = %s.__new__(%s)
[18:50] <stakkars> nice, but why that? I thought my source to be translated is much less restricted than genc's, and *I* have to expect all kinds of strange things. Oh well.
[18:50] <stakkars> self.initcode.append(
[18:50] <stakkars> '_new = space.getattr(%s, %s)\n'
[18:50] <stakkars> '_tup = space.newtuple([%s])\n'
[18:50] <stakkars> 'm.%s = space.call(_new, _tup)' % (
[18:50] <stakkars> cls, self.nameof('__new__'), cls, name))
[18:51] <arigo> which can be spelled
[18:51] <arigo> space.call_method(%s, '__new__', %s)
[18:53] <stakkars> :"> ick, that's overdue
[18:55] <arigo> btw, module/test/test_zip has one failure?
[18:57] <pedronis> it passed for me
[19:00] <arigo> argh
[19:01] <arigo> it crashes if the current directory has a 'test' subpackage
[19:02] <stakkars> about call_method: I think I was after speed and wanted the wraps happen only once. Dos not make sense,does it?
[19:02] Action: stakkars wonders why his client underlines, now
[19:05] <stakkars> udir has strange bugs.
[19:06] <stakkars> if I want to use udir, and I still have some process sitting in an older folder, I get
[19:06] <stakkars> WindowsError: [Errno 5] Zugriff verweigert removing f:\tmp\usession-463
[19:06] <arigo> did you update the 'py' lib recently? or only updated inside 'pypy' ?
[19:07] <stakkars> only inside pypy, I admit.
[19:07] idnar (mithrandi@idnar.user) joined #pypy.
[19:07] <arigo> I think it's been fixed now.
[19:08] <stakkars> no, it'snot.
[19:09] <stakkars> path.remove simply removes, without error handling, and the failure occours in shutil.py, with no exception handling as well.
[19:09] <arigo> then you didn't update... I see:
[19:10] <arigo> try:
[19:10] <arigo> path.remove(rec=1)
[19:10] <arigo> except py.error.Error:
[19:10] <arigo> pass
[19:10] <stakkars> I just did, got no update.
[19:10] <stakkars> I guess somebody did not check in
[19:11] <arigo> but you have the above 4 lines in py/path/local/local.py:467 ?
[19:12] <stakkars> yes. Maybe the except clause does not catch the error on WIndows.
[19:12] <stakkars> Yes, it's a WIndowsError
[19:13] <arigo> but it's a subclass of OSError, which is caught elsewhere
[19:15] <arigo> ah I see
[19:15] <arigo> Errno 5 is not listed in a dict called _winerrnomap
[19:16] <arigo> I'm not clear about hpk's policy about 'py.error' in the py lib
[19:16] <arigo> apparently, errors with known errno only are turned into py.error.Error's
[19:16] <arigo> the other ones are unmodified
[19:19] <arigo> oh wait, it was not intended
[19:19] <arigo> on non-Windows, you always get a py.error.Error
[19:19] <arigo> even a subclass of it, built dynamically if needed for the errno
[19:20] <stakkars> in which file are you? I can fix it, although I will never get used to py's strange name space...
[19:20] <arigo> I'll look in the svn logs to make sure about what was intended there...
[19:21] <arigo> I'm in misc/error.py and py/path/common.py
[19:21] <stakkars> thx
[19:21] <arigo> _getwinerrnoclass()
[19:22] <arigo> oh wait no I see
[19:22] <arigo> maybe
[19:22] <arigo> what is misc/error's _winerrnomap ??
[19:23] <stakkars> _winerrnomap = {
[19:23] <stakkars> 3: py.std.errno.ENOENT,
[19:23] <stakkars> 267: py.std.errno.ENOTDIR,
[19:23] <stakkars> }
[19:23] <stakkars>
[19:24] <stakkars> does posix have somethinglike access denied?
[19:24] <arigo> sure
[19:24] <arigo> on Posix, WindowsError doesn't exist, obviously
[19:25] <stakkars> yes, but errno 5 can be mapped.
[19:25] <arigo> you always get OSError, and the e.errno matches a constant in the 'errno' module
[19:25] <arigo> now on Windows you get a WindowsError only sometimes, an OSError otherwise
[19:26] <stakkars> strange.
[19:26] Action: stakkars wonders why he is no longer underlining. Would like to control this more actively
[19:28] <arigo> well something should be done to turn all "unknown" WindowsErrors into a py.error.Error at least
[19:29] <arigo> got to leave, now
[19:29] <stakkars> yes, even if we don't have a good errno mapping, we shouldwrap it into something.
[19:29] <arigo> probably into the base Error class
[19:29] <stakkars> ok if I add error 5 here, or not?
[19:30] <arigo> yes, I guess so, but make sure you map it to the correct value from errno
[19:30] <arigo> maybe it's EPERM but there is also another candidate if I remember correctly
[19:30] <stakkars> I remember hpk and I were not sure about this, too.
[19:30] <stakkars> will pick the wrong one :)
[19:31] <arigo> :-)
[19:31] <arigo> see you
[19:31] <stakkars> bye
[19:31] arigo (~arigo@vicky.ecs.soton.ac.uk) left irc: "leaving"
[19:31] <stakkars> I think EACCES is ok
----- silence for 1 hr and 1 minute ----- [20:32] <stakkars> about "something should be done to turn all "unknown" WindowsErrors into a py.error.Error at least":
[20:32] <stakkars> I'm not sure if we should do that.
[20:35] <stakkars> If we stumble over a new error, we need to add it to the windows errors dict.
[20:35] <stakkars> Here, the surrounding code was
[20:35] <stakkars> try:
[20:35] <stakkars> [18:05] arigo: path.remove(rec=1)
[20:35] <stakkars> [18:05] arigo: except py.error.Error:
[20:35] <stakkars> [18:05] arigo: pass
[20:36] <stakkars> it was actually *good* not to have any default, because it made us make the dict more complete.
----- silence for 37 minutes ----- [21:13] esteban (estevam_@81.60.228.39) joined #pypy.
----- silence for 40 minutes ----- [21:53] hpk (~hpk@mail.trillke.de) joined #pypy.
[21:54] Continuity (~kittish@host81-153-48-22.range81-153.btcentralplus.com) joined #pypy.
----- silence for 24 minutes ----- [22:18] Action: pedronis leaving the office
[22:18] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "ChatZilla 0.9.61 [Mozilla rv:1.7.3/20041007]"
[22:21] tea (~tea@cap006-001.kcn.ne.jp) left irc: "using sirc version 2.211+KSIRC/1.3.10"
----- silence for 40 minutes ----- [23:01] pedronis (~Samuele_P@c-1e8b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 20 minutes ----- [23:21] <stakkars> I broke something when trying to make names in genc.py shorter.
[23:22] <stakkars> If I cannot repair this this evening, we need to revert to rev. 9523 of this file.
[23:30] <stakkars> disabled the feature for the moment but left the code in.
[00:00] --- Wed Mar 2 2005