[00:05] pedronis_afk (~Samuele_P@c-398b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.67 [Firefox 1.0/20041107]"
----- silence for 1 hr and 8 minutes ----- [01:13] arigo (~arigo@134.99.18.225) left irc: "[x]chat"
----- silence for 1 hr and 34 minutes ----- [02:47] enord (Acer@219.95.159.127) joined #pypy.
[02:51] idnar (mithrandi@idnar.user) left irc: Read error: 60 (Operation timed out)
----- silence for 21 minutes ----- [03:12] enord (Acer@219.95.159.127) left irc: "Hey! Where'd my controlling terminal go?"
----- silence for 1 hr and 25 minutes ----- [04:37] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: Read error: 60 (Operation timed out)
----- silence for 1 hr and 22 minutes ----- [05:59] fserb (~fserb@201-1-13-13.dsl.telesp.net.br) joined #pypy.
----- silence for 39 minutes ----- [06:38] fserb (~fserb@201-1-13-13.dsl.telesp.net.br) left irc: Client Quit
[06:51] sanxiyn (~tinuviel@211.104.100.115) joined #pypy.
----- silence for 1 hr and 16 minutes ----- [08:07] arigo (~arigo@134.99.18.225) joined #pypy.
----- silence for 59 minutes ----- [09:06] idnar (mithy@idnar.user) joined #pypy.
[09:14] stakkars (rrukve@i528C1130.versanet.de) left irc: Read error: 148 (No route to host)
[09:29] sanxiyn (~tinuviel@211.104.100.115) left irc: "Bye"
[09:30] arigo (~arigo@134.99.18.225) left irc: Read error: 111 (Connection refused)
----- silence for 41 minutes ----- [10:11] rQ{y|jl_]} (nZOTGC@c-24-11-226-131.hsd1.in.comcast.net) joined #pypy.
[10:11] rQ{y|jl_]} (nZOTGC@c-24-11-226-131.hsd1.in.comcast.net) left #pypy.
[10:16] [rQ{y|jl_]}!nZOTGC@c-24-11-226-131.hsd1.in.comcast.net] Come watch me on my webcam and chat /w me :-) http://c-24-11-226-131.hsd1.in.comcast.net:3622/me.mpg
[10:17] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
[10:21] sanxiyn (~tinuviel@211.104.100.115) joined #pypy.
----- silence for 17 minutes ----- [10:38] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: Read error: 113 (No route to host)
[10:48] <sanxiyn> Anyone awake?
[10:49] <sanxiyn> Anyway, just to let you know that Gadfly runs on PyPy.
[10:50] <sanxiyn> (Tested simple CREATE/INSERT/SELECT. Takes a full hour to finish :-)
[10:50] <sanxiyn> Now checking in under goal/ ...
[11:03] <sanxiyn> SimpleHTTPServer.test() works too.
[11:03] <sanxiyn> (Well, no surprise...)
[11:07] ludal (~ludal@logilab.net2.nerim.net) joined #pypy.
[11:10] <sanxiyn> ludal: Hello
----- silence for 59 minutes ----- [12:09] stakkars (~tismer@82.144.60.19) joined #pypy.
[12:10] <sanxiyn> It seems python py.py py.py is broken for some time now.
[12:15] <stakkars> oh
[12:23] arigo (~arigo@vicky.ecs.soton.ac.uk) joined #pypy.
[12:24] mwh2 (~user@modem-184.erendis.dialup.pol.co.uk) joined #pypy.
[12:25] <stakkars> sanxiyn: well, I think we have some trouble with faking the new module.
[12:25] <stakkars> for instance, try:
[12:26] <stakkars> import new
[12:26] <stakkars> print new.function.__doc__
[12:26] <stakkars> and you see something is quite broken.
[12:26] arigo_ (~arigo@vicky.ecs.soton.ac.uk) joined #pypy.
[12:26] <stakkars> hi Armin
[12:26] <arigo> hi!
[12:26] arigo (~arigo@vicky.ecs.soton.ac.uk) left irc: Client Quit
[12:26] Nick change: arigo_ -> arigo
[12:26] <mwh2> ??
[12:26] <stakkars> py.py py.py doesn't work any longer.
[12:27] <stakkars> It seems to have trouble with a faked new module.
[12:27] <stakkars> for instance, start py.py and use print new.function.__doc__
[12:27] <mwh2> new is pure python
[12:27] <mwh2> def f(): pass
[12:27] <mwh2> print type(f).__doc__
[12:28] <mwh2> should be identical
[12:28] <arigo> indeed, it's the __doc__ attribute that is broken (blame me)
[12:28] <sanxiyn> stakkars: Eh, does py.py py.py breaks for you near __doc__?
[12:29] <sanxiyn> My guess was something's wrong with importing path...
[12:30] Action: mwh2 has been thinking about slots and so on again
[12:30] <mwh2> my head hurts
[12:31] <stakkars> no, it breaks with TypeError: default __new__ takes no parameters
[12:31] <stakkars> in line 10 of hack.py, where a new.function() is tried.
[12:31] <stakkars> SO I guessed we have some trouble with faking builtin modules, here.
[12:32] <arigo> stakkars: no it's a different problem
[12:33] <arigo> stakkars: simply that function.__new__ is broken (or gone missing)
[12:33] <stakkars> faking a module out of a faked one seemed funny to me.
[12:33] <arigo> unrelated to faking.
[12:33] <stakkars> ok, but how can __new__ be missing? We are in function.new which is a builtin ???
[12:33] <arigo> no no
[12:34] <arigo> function.new is types.FunctionType
[12:34] <stakkars> :-()
[12:34] <mwh2> new.function, you mean :)
[12:34] <arigo> yes :-)
[12:34] <stakkars> hrmpf,yes
[12:34] <arigo> some descriptor question about doc:
[12:35] <arigo> is there any sane way to declare a Python new-style class
[12:35] <arigo> such that X.__doc__ is the class docstring and X().__doc__ is something else per-instance?
[12:36] <stakkars> didn't we solve that, lately, or was it different?
[12:36] <arigo> no it's always the same problem
[12:36] <arigo> it's why new.function.__doc__ is strange
[12:36] <stakkars> but what did we do, was it old-style?
[12:37] <arigo> no, we did:
[12:37] <arigo> module/builtin/app_descriptor.propertydoc
[12:38] <arigo> but now I just realized that we have the same problem not just on property vs property(), but also on type vs <any type>
[12:38] <arigo> so I'm wondering is there is a sane solution
[12:38] <stakkars> sure, this is a bit different, but same breed.
[12:39] <mwh2> arigo: i have my doubts (about there being a sane solution)
[12:39] <stakkars> it just needs to be as messy as CPython does it, that's enough :-)
[12:40] <arigo> well I can see two ways
[12:40] <arigo> CPython's is to hide the docstring in tp_doc, which is only read from the __doc__ descriptor of types
[12:40] <arigo> alternatively we could "officialise" the propertydoc hack
[12:41] <stakkars> on the sane way to create such a class, what is wrong with this class? :
[12:41] <stakkars> >>> class A(object):
[12:41] <stakkars> ... """huh"""
[12:41] <stakkars> ... def __init__(self):
[12:41] <stakkars> ... self.__doc__ = "hallo"
[12:41] <stakkars> ...
[12:41] <stakkars> >>> x=A()
[12:41] <stakkars> >>> A.__doc__
[12:41] <stakkars> 'huh'
[12:41] <stakkars> >>> x.__doc__
[12:41] <stakkars> 'hallo'
[12:41] <stakkars> >>>
[12:42] <arigo> the "small" problem is that A.__doc__ is used as default; the "big" problem is that we actually want a __doc__ slot (or getset property)
[12:43] <mwh2> arigo: i think something like propertydoc is the Right Thing
[12:43] <arigo> :-)
[12:43] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
[12:44] <mwh2> though, possibly
[12:45] <mwh2> argh
[12:45] Action: mwh2 feels his brain swelling dangerously
[12:45] cfbolz (~cfbolz@hdlb-3e342017.pool.mediaWays.net) joined #pypy.
[12:45] <mwh2> class propertydoc(object):
[12:45] <mwh2> def __get__(self, p, cls=None):
[12:45] <mwh2> if p is None:
[12:45] <mwh2> return cls.__doc__
[12:45] <mwh2> else:
[12:45] <mwh2> return PROPERTY_DOCSLOT.__get__(p) # on an instance
[12:45] <mwh2>
[12:45] <mwh2> would be an infinite recursion, right?
[12:46] <arigo> yes
[12:46] <mwh2> but still, we want something like that
[12:46] <mwh2> only, working
[12:47] <arigo> but the "class property" statement cannot have a normal docstring, it must set __doc__ to propertydoc()
[12:47] <arigo> because we cannot write to the __doc__ attribute of types in CPython
[12:47] <arigo> after they are built :-(
[12:47] <stakkars> right, this is R/O. But why do we want doc slots at all? They don't work in Python, either.
[12:48] <arigo> they can be made to work in Python
[12:48] <arigo> that's the purpose of the propertydoc hack: it works in CPython
[12:49] <stakkars> so you want to imporve Py(thon|Py) at the same time! :-D
[12:49] <arigo> it was all triggered by the goal to make class property have slots
[12:49] <arigo> stakkars: not really
[12:50] <arigo> we're looking for a hack that works in CPython but is also the Right Thing in the mwh sense
[12:50] <arigo> and can be used for the 'type' type.
[12:50] <mwh2> well
[12:51] <mwh2> with sufficient magic, you should surely be able to write
[12:51] <mwh2> class property(object):
[12:51] <mwh2> __doc__ = '...'
[12:51] <mwh2> in pypy and have it work?
[12:51] <mwh2> after all, we control type_new...
[12:51] <arigo> you mean,
[12:51] <arigo> __doc__ = 'stuff'
[12:52] <arigo> __slots__ = ['__doc__']
[12:52] <arigo> ?
[12:52] <mwh2> oh, i don't know
[12:52] <mwh2> sorry :)
[12:53] <cfbolz> hi!
[12:53] <arigo> hi!
[12:54] Action: stakkars is googling for the definition of "mwh sense" :-X
[12:54] <cfbolz> I'm getting some strange import errors when using make_c_from_pyxfile.
[12:55] <cfbolz> somewhere in a Plex file the import of copy fails
[12:55] <mwh2> stakkars: please give me the link
[12:56] <cfbolz> It might be related to some py.test magic since the error changes if I run it with nomagic
[12:56] <mwh2> i do know that there were many subtle and confusing checkins around this issue around the 2.2 release
[12:56] <stakkars> it will probably show up tomorrow in http://nimrod.terra-link.net/pypy
[12:57] <mwh2> ?
[12:57] <mwh2> oh, i see :)
[12:57] <stakkars> :)
[12:58] <cfbolz> Does this sound familiar for someone? (otherwise it's probably some strange bug of mine)
[12:58] hpk (~hpk@merlinux.de) left irc: Read error: 110 (Connection timed out)
[12:58] <arigo> py.test tends to hide import errors
[12:58] <mwh2> cfbolz: no, not off hand, i'm afraid
[12:58] hpk (~hpk@merlinux.de) joined #pypy.
[12:59] <cfbolz> well, the error final error is:
[12:59] <cfbolz> E class Error(Exception):
[12:59] <cfbolz> ~ AttributeError: << Class instance has no attribute 'filename'
[12:59] <cfbolz> in copy.py
[12:59] <arigo> not exactly sure why or from when, but the other day I got a mere ImportError that was caused by some other error somewhere else while importing
[12:59] <cfbolz> yes, could be something like that
[13:02] <cfbolz> Ok, I'll probably have to dig some more :-(
[13:02] <stakkars> if you are afraid this is related to my gateway.applevelinterp, there is a line to uncomment,
[13:02] <stakkars> which will fall back to no interplevel action,maybe this has a bug not caught by the tests.
[13:04] <cfbolz> I don't think this is related. Anyway, where is this line?
[13:04] <stakkars> below the definition of applevelinterp, there is an assignment that sets applevelinterp back to applevel.
[13:05] <cfbolz> ah, got it. I'll try - thanks
[13:06] <stakkars> since there is some fiddling with simplify and friends, and also the rules about variable lifetime seem to be not really consistent, yet, I fear some interaction.
[13:07] <cfbolz> nope, didn't do anything. I guess it's some stupid error of mine.
[13:07] <stakkars> fine to know, anyway.
[13:07] <cfbolz> :-)
[13:09] <stakkars> arigo: justto add to the bulk of open problems: I added a patch to listobject yesterday which should
[13:09] <cfbolz> well, see you later.
[13:09] <stakkars> be stable against any future decision about variable lifetime, but in fact I'm a bit struggling with this:
[13:09] cfbolz (~cfbolz@hdlb-3e342017.pool.mediaWays.net) left irc: "Verlassend"
[13:10] <stakkars> if remove_unused_vars simply removes variables which are defined by the user, this might be
[13:11] <stakkars> fine for genc et al. But the same thing is used for interplevel translation, and the semantic change is
[13:11] <stakkars> not trivial for existing Python code.
[13:12] <arigo> possibly, indeed
[13:12] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[13:12] <arigo> but that's all part of the "interplevel is only for R-Python-enough app-level code" agreement, so far
[13:13] <stakkars> yes, that's right. But this is a rule that really needs to be added to the non-existing RPython definition! :-)
[13:13] Action: mwh2 grumbles about destructors in general
[13:14] <mwh2> though, weakrefs are enough here
[13:14] <stakkars> And we need to define how we safely can express "don't collect this early".
[13:14] <stakkars> Samuele suggested yesterday, I should use that recycle variable as a parameter for a dummy procedure,
[13:15] <stakkars> to make it survive. I don't think this will hold in the long-term, when we optimize and get rid of such functions.
[13:15] <arigo> you used it in a del recycle[:] operation, which looks fine
[13:16] <stakkars> The other suggestion which I used then was del recycle[:]. Can we guarantee this to be stable against design changes of the compiler?
[13:16] cfbolz (~cfbolz@hdlb-3e342055.pool.mediaWays.net) joined #pypy.
[13:17] <stakkars> In a better world, we would automagically figure out that recycle was filled with references *by intent*, but this is probably not easy...
[13:17] <mwh2> heh, no
[13:18] <stakkars> and why is del recycle[:] fine, but delrecycle won't work?
[13:18] <arigo> del recycle[:] is an operation
[13:19] <arigo> it would be recycle.clear() if lists had a clear method
[13:19] <stakkars> well, I also could run though it with another loop, I guess. But flowgraphs have no idea about a container, that is.
[13:20] <arigo> well that's fine as it is now
[13:20] <cfbolz> I found my bug (*really* stupid) and... I catched my first exception!!!
[13:20] <arigo> :-)
[13:23] <cfbolz> Ok, I'll clean it up and check it in. See you.
[13:23] cfbolz (~cfbolz@hdlb-3e342055.pool.mediaWays.net) left irc: "Verlassend"
[13:26] <mwh2> arigo: nice code, at first reading
[13:26] <mwh2> can it be appropriated for types.FunctionType too?
[13:32] dlk (~dlk@walter.ita.chalmers.se) joined #pypy.
[13:35] mwh2 (~user@modem-184.erendis.dialup.pol.co.uk) left irc: "bye"
[13:41] <dlk> People, I need to start taking notes about what dates are needed for sprinting during EuroPython 2005. Read the announcement and respond to the europython-list. http://www.europython.org/sections/sprints_and_wiki/dates_for_sprinting Thanks!
----- silence for 38 minutes ----- [14:19] <arigo> mwh2: possibly
[14:22] Action: hpk wonders if anything is fixed now regarding the oxford sprint
[14:24] <arigo> unclear
[14:27] <arigo> I guess the built-in types with a __doc__ field can somehow steal this definition
[14:36] <arigo> grumble, there is already some duplication of descriptor classes:
[14:37] <arigo> GetSetProperty vs property
[14:37] <arigo> StaticMethod vs staticmethod
[14:39] <pedronis> it's there also CPython to some extent
[14:40] <arigo> but in our case it's two classes really equivalent
[14:41] <arigo> the user-visible one could simply be removed and replaced by the internal one
[14:41] <arigo> so I'm wondering if we could keep the app-level definition and geninterpify it early
[14:52] <stakkars> apropos: I'm in trouble with app_descriptor.py, can't flow that one,probably because
[14:52] <stakkars> classmethod.__get__ uses local function defs.
[14:53] <stakkars> should I a) leave this untranslated, b) try to make flow space able to do local defs or c) rewrite the method?
[14:54] <arigo> let's try c)
[14:54] dlk (dlk@walter.ita.chalmers.se) left #pypy.
[14:54] <arigo> classmethod.__get__ could return a bound method object.
[14:54] <stakkars> absolutely
[14:56] <stakkars> using a small helperclass, or something shorter possible?
[14:58] <arigo> well I'd almost write return self._f.__get__(klass)
[14:58] <arigo> but only almost :-)
[15:00] <arigo> instead, return MethodType(self._f, klass)
[15:00] <arigo> with def dummy(): pass; MethodType = type(dummy.__get__(42)) in the globals
[15:11] <stakkars> ok,I tried
[15:11] <stakkars> def __get__(self, obj, klass=None):
[15:11] <stakkars> if klass is None:
[15:11] <stakkars> klass = type(obj)
[15:11] <stakkars> return MethodType(self._f, klass)
[15:11] <stakkars> def dummy(): pass
[15:11] <stakkars> MethodType = type(dummy.__get__(42))
[15:11] <stakkars> del dummy
[15:12] <stakkars> but then some tests don'tpass:
[15:12] <stakkars> TypeError: descr_method__new__() takes exactly 4 arguments (3 given)
[15:13] <arigo> that's a real bug of our MethodType.__new__
[15:13] <arigo> in CPython the last argument is optional
[15:14] <stakkars> do I fix MethodType.__new__, or supplya default arg?
[15:15] <stakkars> now way, needs to be fixed.
[15:16] <arigo> yes
[15:18] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) joined #pypy.
[15:19] <arigo> can I check function.py in ?
[15:19] <arigo> I also added a few comments in there
[15:19] <stakkars> yes,fine with me
[15:20] <arigo> done
[15:21] <stakkars> stillfailing
[15:23] <stakkars> probablyatypo? not space_is_w(w_cls, space.w_None) and
[15:23] <arigo> oops
[15:23] <arigo> typo indeed
[15:23] <stakkars> in test_function.py line 247
[15:23] <stakkars> fixed
[15:23] <arigo> thanks
[15:25] Action: arigo reads, horrified, a long blog posting about essentially how to do __nonzero__ safely in C++
[15:27] <arigo> stakkars: any chance to geninterpify app_descriptor now?
[15:28] <stakkars> I am testing, but just got disturbed by a customer... hand on :-)
[15:28] <stakkars> hang on
[15:41] <stakkars> hmm, I'm now crashing in a class where __module__ is None
[15:43] <arigo> interesting
[15:43] <stakkars> a bit hard to find where this is, ...
[15:46] <stakkars> ouch, no it is a missing __name__ property of NoneType. Must do further debugging...
[15:48] <stakkars> ok, a deficiency of mine, need to add instancemethod to typename_mapping or somethingeeek
[15:48] <arigo> eeek indeed
[15:48] <arigo> it's the Constant(MethodType), I guess
[15:49] <stakkars> yes, I think so.
[15:51] <stakkars> ok, I will probably fake it in applevel with a "type((lambda:42).__get__(42))"
[15:54] arigo_ (~arigo@vicky.ecs.soton.ac.uk) joined #pypy.
[15:55] <stakkars> hmm, now I crash in error.py, line 18
[15:56] <stakkars> that is:
[15:56] <stakkars> assert w_type is not None, w_value
[15:56] <stakkars> but the reported error is
[15:56] <stakkars> AssertionError: ("global name '_issubtype' is not defined")
[15:57] <stakkars> haeh
[15:58] <stakkars> ok,got quite far, over 600 lines are generated, and I crash when flowing some __init__ function.
[16:00] <stakkars> arigo: what is _issubtype ???
[16:00] arigo (~arigo@vicky.ecs.soton.ac.uk) left irc: Read error: 60 (Operation timed out)
[16:00] <stakkars> is this (again) a magin addition to the builtins which is not defined in CPython?
[16:01] <pedronis> yes, it is a interp-level helper for some of the builtins defined at app-level
[16:02] <stakkars> I see. ouack stuff :-D
[16:04] <stakkars> so do I put something like
[16:04] <stakkars> def _issubtype(space, w_cls1, w_cls2):
[16:04] <stakkars> return space.issubtype(w_cls1, w_cls2)
[16:04] <stakkars> into my builtins?
[16:04] <stakkars> or should I import a whole module?
[16:09] arigo (~arigo@134.99.18.225) joined #pypy.
[16:10] sanxiyn_ (tinuviel@222.233.187.43) joined #pypy.
[16:11] <stakkars> arigo: I'm not stuck at a missing _issubtype in CPython.
[16:11] <arigo> I read that.
[16:12] <stakkars> not sure what to do about it. Probably a dummy definition would do, since I'm special-casing builtins, anyway.
[16:12] <arigo_> yes, anything that gives a 'space.issubtype()' in the final code is fine :-)
[16:13] <arigo> I agree
[16:13] <arigo_> (just kidding, there isn't two myselves)
[16:13] <sanxiyn_> Hello
[16:13] Action: sanxiyn_ starts reading backlog
[16:14] <stakkars> one session per brain-half would make things quite funny.
[16:19] <stakkars> ok,made that hurdle.
[16:19] Action: sanxiyn_ done reading
[16:24] <stakkars> slots problem,got a slot names list with justa None in it. hmmmm
[16:26] <stakkars> ok, probably my code, again. I should havemore tests on stuff like slots :-)
[16:27] <sanxiyn_> http://deadbeefbabe.org/paste/202 is what I got with py.py py.py.
[16:27] <sanxiyn_> Traceback includes py library. I wonder what's going on...
[16:30] <stakkars> ahh, list initialization comes too late!
[16:30] Action: sanxiyn_ disables py.code.compile in pypy.tool.compile.compile2.
[16:33] <arigo> stakkars: aargh
[16:33] <arigo> sanxiyn_: apparently, just typing 'import inspect' in py.py takes ages
[16:34] <sanxiyn_> arigo: Not that.
[16:34] <arigo> sanxiyn_: but eventually succeeds, indeed
[16:34] <stakkars> arigo: it works now!
[16:34] <sanxiyn_> arigo: It doesn't find imp.py under lib/.
[16:34] <arigo> ah
[16:34] <arigo> stakkars: great!
[16:34] <sanxiyn_> arigo: I guess some sys.path confusion here, but can't find exact problem.
[16:34] <stakkars> current problem: I have no way to control what to trnaslate and what not.
[16:35] <stakkars> So I'm just testing with a modified lazymodule, which is quite much!
[16:36] <arigo> a magic flag in the app_* module, maybe
[16:36] <stakkars> I think I'm now crashing in app_io
[16:36] <stakkars> maybe I should add a NOT_RPYTHON to the module doc string and fall back to applevel, for instance?
[16:37] <sanxiyn_> What is the easiest way to test whether one's in PyPy or not?
[16:37] <stakkars> hit ctrl-c
[16:37] <sanxiyn_> Eh, in the code.
[16:37] <stakkars> :-)
[16:38] <sanxiyn_> 'pypy' in sys.version?
[16:38] <stakkars> think so
[16:39] <pedronis> hasattr(sys,'pypyp_objspaceclass')
[16:39] <pedronis> hasattr(sys,'pypy_objspaceclass')
[16:39] <sanxiyn_> thanks
[16:44] <sanxiyn_> arigo: Any guess when pypy/lib is inserted to sys.path?
[16:45] <sanxiyn_> (After removing py lib refs and disabling hacks that seems to do with debug, I get ImportError with _formatting.)
[16:45] <hpk> sanxiyn_: in module/sys2/state.py setinitalpath()
[16:45] <arigo> sanxiyn_: maybe in module/sys2/state.py
[16:46] <arigo> :-)
[16:46] <hpk> :-)
[16:46] <sanxiyn_> How late (or early) is that...?
[16:46] <hpk> sanxiyn_: lemme see
[16:47] <hpk> very early
[16:48] <hpk> in baseobjspace's ObjSpace.make_builtins() the access
[16:48] <hpk> w_modules = self.sys.get('modules')
[16:49] <hpk> leads to loading the "modules" name via "state.get(space).w_modules"
[16:49] <sanxiyn_> Okay.
[16:50] <hpk> btw, these indirections allow to have multiple module instances for multiple object spaces
[16:53] <stakkars> arigo: interesting flow problem:
[16:54] <stakkars> in the def of dir(), there is a _class --- ooops ----
[16:54] <stakkars> I see there is a local func definition, again.
[16:54] <stakkars> Do we fix that?
[16:54] <stakkars> for now, I disable the thing.
[17:03] <arigo> just move _classdir() out of the function
[17:03] <arigo> it was put there a long time ago, when we had to hide the names (otherwise they'd appear in the user __builtin__)
[17:04] <stakkars> ok, didn't look at all, I'm at the next problem with property instances in complex.Ok, will do that.
[17:07] <stakkars> gack! now I'm hit by *your* merge of all functions with the init function: globals are broken :-)
[17:08] <arigo> ?
[17:08] <stakkars> app_inspect defines globals()
[17:08] <stakkars> but my init code,now in the same namespace, uses globals()
[17:09] <sanxiyn_> Sigh. Now PyPy on PyPy actually goes to import StdObjSpace...
[17:11] <arigo> stakkars: I bounce the blame back to you, with your tries to generate functions with non-mangled names :-)
[17:11] <stakkars> thanks :-)
[17:13] <sanxiyn_> arigo: PyPy imports descroperation, descroperation imports operator (why?), which is C module, and that's (I think) before pypy/lib insertion.
[17:16] <hpk> arigo: it seems that svn slightly changed behaviour with respect to changing externals
[17:17] <hpk> arigo_: now re-pointing a name to a different URL renames the old directory to "*.OLD" and checks out stuff apparently
[17:17] <arigo> hpk: ah, good
[17:17] idnar (mithy@idnar.user) left irc: "kbye"
[17:17] <arigo> sanxiyn_: I'm not sure I understand how this causes a problem
[17:18] <sanxiyn_> arigo: It seems to cause ImportError :(
[17:18] <sanxiyn_> Something's wrong.
[17:24] <arigo> ah, wait
[17:25] <arigo> the bit in setinitialpath that adds lib-python-2.3.4 into sys.path shouldn't be executed again by pypy on top of pypy
[17:25] <arigo> this is probably what causes extreme confusion
[17:25] <sanxiyn_> Hm...
[17:25] <arigo> Hm...
[17:25] Action: sanxiyn_ inserted print sys.path here and there, kicked off py.py py.py, and waits.
[17:26] <arigo> it causes extreme confusion in my head, but maybe nowhere else
[17:28] <sanxiyn_> Okay.
[17:30] <sanxiyn_> http://deadbeefbabe.org/paste/204
[17:30] <sanxiyn_> print sys.path inserted at top of descroperation.py.
[17:30] <sanxiyn_> It's imported before setinitialpath, I think.
[17:31] <stakkars> arigo: got *quite* far. But now, app_descriptor creates side effects when I start PyPy
[17:31] <stakkars> when I make it NOT_RPYTHON,all seems fine.
[17:32] <stakkars> whenenabled, it causes this in types.py:
[17:32] <stakkars> File "D:\pypy\dist\pypy\lib\types.py", line 34 in ?
[17:32] <stakkars> ComplexType = complex
[17:32] <stakkars> (application-level) <W_TypeObject(AttributeError)>: <UserW_ObjectObject() instan
[17:32] <stakkars> ce of <W_TypeObject(AttributeError)>>
[17:32] <stakkars> funny, eh?
[17:32] <arigo> hum
[17:33] <arigo> sanxiyn_: I'm confused, setinitialpath is called by the pypy #1 before even starting the pypy #2
[17:34] <sanxiyn_> arigo: Yes... but sys.path ran by pypy #2 (I think) shows it doesn't have effect. No?
[17:34] <arigo> sanxiyn_: maybe the pypy #2 manipulates back the sys.path, e.g. when interpreting site.py
[17:34] <sanxiyn_> site.py?!
[17:35] <sanxiyn_> Does PyPy run site.py?
[17:35] <arigo> dunno, actually
[17:35] <sanxiyn_> I don't think so.
[17:35] <arigo> ok
[17:36] <arigo> ah
[17:36] <arigo> it might be autopath's fault
[17:37] <hpk> poor little autopath, always gets blamed
[17:37] <arigo> :-)
[17:37] <arigo> for sanity,
[17:37] <sanxiyn_> Shoot, it seems.
[17:37] Action: hpk doesn't even start to think about import problems at "py.py py.py" level
[17:37] <arigo> maybe try making two copies of the whole pypy/dist directory
[17:37] <arigo> use one to interpret the other
[17:37] <sanxiyn_> if os.path.realpath(orig).startswith(pypy_root):...
[17:38] <sanxiyn_> (orig being sys.path[:] element!)
[17:38] <sanxiyn_> That will surely remove pypy/lib out of sys.path.
[17:38] <stakkars> waaaah
[17:39] <stakkars> it is my own helper which tries "import types" during initialization. aaaargh
[17:39] <arigo> stakkars: :-)
[17:39] <sanxiyn_> arigo: Is my analysis correct...?
[17:39] <arigo> sanxiyn_: I think so
[17:39] <sanxiyn_> arigo: Why does autopath remove anything start with pypy_root?
[17:40] <arigo> to remove paths that are subpackages, i.e. have an __init__.py in them
[17:40] <stakkars> probably with no import of types, but using the type((lambda:42).__get__(42)) trick it might work :-)
[17:40] <arigo> a fix to autopath would be to only remove dirs that really have an __init__.py
[17:40] <arigo> as neither pypy/lib nor lib-python-2.3.4 have one.
[17:40] <arigo> stakkars: guess so :-)
----- silence for 21 minutes ----- [18:01] <sanxiyn_> arigo: Eh, please enlighten me why autopath need to remove paths that are subpackages...?
[18:08] <arigo> sanxiyn_: I think that's because otherwise
[18:08] <arigo> you would have e.g. pypy/interpreter/ in sys.path when you start py.py
[18:09] <sanxiyn_> And...
[18:09] <arigo> that's bad
[18:09] <arigo> it can cause confusion
[18:10] <sanxiyn_> Okay.
[18:10] <sanxiyn_> Now, after fixing autopath, and confirmed that sys.path print in descroperation is sane, now I get...
[18:10] <sanxiyn_> StructError: P is not a valid format :-(
[18:10] <sanxiyn_> well.
[18:11] tic (~vision@c-996e73d5.019-35-67626717.cust.bredbandsbolaget.se) joined #pypy.
[18:11] <stakkars> arigo:something weird is happening:
[18:11] <stakkars> when I start PyPy and simply type
[18:11] <stakkars> complex
[18:12] <stakkars> I get
[18:12] <stakkars> AttributeError: 'property' object attribute '__doc__' is read-only
[18:13] <stakkars> this happens when I translated app_descriptor.*gulp*
[18:13] <arigo> uh
[18:13] <arigo> sanxiyn_: I guess our struct.py doesn't include this recent format character...
[18:14] <sanxiyn_> arigo: It's used in pypy.tool.uid, whose purpose I'm not quite sure.
[18:14] <arigo> sanxiyn_: it's to know the underlying platform's pointer size.
[18:15] <arigo> stakkars: ah
[18:15] <stakkars> ah, and idea?or ah, no clue
[18:17] <arigo> ah, no clue
[18:21] <stakkars> hmm, it actually happens in generated code for fastf_property___init__
[18:22] <stakkars> last line here crashes:
[18:22] <stakkars> if goto == 1:
[18:22] <stakkars> w_0 = space.setattr(w_self, gs_fget, w_fget)
[18:22] <stakkars> w_1 = space.setattr(w_self, gs_fset, w_fset)
[18:22] <stakkars> w_2 = space.setattr(w_self, gs_fdel, w_fdel)
[18:22] <stakkars> w_3 = space.setattr(w_self, gs___doc__, w_doc)
[18:22] <arigo> ahAHahAH
[18:22] <arigo> the docstring of class property is a bit special
[18:22] <arigo> it's not a string
[18:22] <arigo> :-)
[18:23] <stakkars> bruhaha :-D
[18:23] <stakkars> ba-zong
[18:26] <sanxiyn_> shoot
[18:28] <stakkars> ...lost in translation...
[18:29] <sanxiyn_> Did I break tests? It seems...
[18:31] <stakkars> ok, the initialization is correct, as in the source:
[18:31] <stakkars> def __init__(self, fget=None, fset=None, fdel=None, doc=None):
[18:31] <stakkars> self.fget = fget
[18:31] <stakkars> self.fset = fset
[18:31] <stakkars> self.fdel = fdel
[18:31] <stakkars> self.__doc__ = doc
[18:31] <stakkars> but the translation to space.setattr does not work, because of the special __doc__.
[18:32] <arigo> m.
[18:32] <stakkars> can I know this from geninterplevel? I guess not really.
[18:32] ludal (ludal@logilab.net2.nerim.net) left #pypy.
[18:32] <stakkars> in this case I need to know that it is a special thing.
[18:33] <arigo> change the source to setattr(self, '__doc__', doc) with an XXX comment ?
[18:35] <stakkars> produces exactly the same code and doesn't work exactly the same
[18:36] <sanxiyn_> Hm, it seems it's not my fault.
[18:36] <sanxiyn_> Currently, half the tests break...
[18:37] <sanxiyn_> But I think it breaks inside py.test.
[18:38] <sanxiyn_> Any recent checkin to py.test?
[18:40] <sanxiyn_> No, not py.test then.
[18:40] <pedronis> there were some new llvm tests that were missing the skip logic
[18:41] <sanxiyn_> pedronis: Eh, something like 400 tests fail for me...
[18:41] <sanxiyn_> (And I have LLVM installed.)
[18:41] <pedronis> I will try again
[18:41] <sanxiyn_> (Is it something stupid on my side? maybe.)
[18:44] <pedronis> I'm running the tests with the autopath changes, we will see
[18:51] <pedronis> sanixyn_: all non-skipped tests pass for me
[18:51] <sanxiyn_> pedronis: Thanks for confirmation.
[18:52] <sanxiyn_> (It must be the case that my PEBCAK)
[19:04] cfbolz (~bolz@zenon.physi.uni-heidelberg.de) left irc: "Leaving"
[19:05] idnar (mithrandi@idnar.user) joined #pypy.
[19:07] <sanxiyn_> idnar: Hello
[19:16] dlk (~dlk@82.96.42.156) joined #pypy.
[19:19] <stakkars> operation.py has a bug:
[19:19] <stakkars> def _issubtype(space, w_cls1, w_cls2):
[19:19] <stakkars> return space.issubtype(w_cls1, w_cls2)
[19:19] <stakkars> but space.issubtype does not accept w_clas2 to be a tupleof types
[19:21] <arigo> _issubtype is an internal function
[19:21] <arigo> a bug would be for a caller of _issubtype to pass a tuple of types
[19:22] <stakkars> yes,but used this way in some places
[19:22] <arigo> ah
[19:22] <arigo> then we have some bugs? :-)
[19:22] <stakkars> so there is a bug on one end, definition dependant
[19:22] <stakkars> noooo, not really :-)
[19:24] <stakkars> it happens in dir() after translation to interp-level. No idea if I'm causing this?
[19:26] <arigo> note that some places actually call _issubtype() with a possible tuple and catch the resulting TypeError
[19:27] <stakkars> ahh. I get
[19:27] <stakkars> (application-level) TypeError: unsupported operand types for issubtype (type, tu
[19:27] <stakkars> ple)
[19:28] <arigo> maybe the TypeError isn't caught by the except: handler
[19:28] <stakkars> maybe a case where an error is not caught due to special exception rules in RPy?
[19:28] <arigo> :-)
[19:28] <arigo> depends on how you hacked _issubtype into place :-)
[19:28] <stakkars> waah, and I still cannot get the doc crap to work.
[19:29] <arigo> head-banging
[19:29] <stakkars> aeh, hu?
[19:29] <stakkars> I just put a dummy into __builtin__
[19:29] <stakkars> that does a late lookup of the thing, then.
[19:30] <stakkars> so the _issubtype is not treated by geninterp at all, only calls to it.
[19:31] <arigo> the dummy in __builtin__ doesn't have to do anything, does it?
[19:31] <stakkars> yes, no
[19:32] <arigo> hum
[19:32] <arigo> maybe _issubtype could be a synonym for issubclass
[19:32] <stakkars> it is late bound
[19:32] <arigo> hum
[19:32] <arigo> ok ok forget it
[19:32] <stakkars> I will check the generated code.
[19:32] <arigo> yes, I guess it's reasonable
[19:32] <pedronis> you would get an infinite recursion I think
[19:33] <arigo> pedronis: hum. ok
[19:33] <arigo> the "except TypeError" clause I was thinking about is in def _issubclass()
[19:35] <stakkars> yes, I'm wading through it
[19:36] <stakkars> first call gets the function and calls it without exception handling, which is fine:
[19:36] <stakkars> w_1 = space.call_function((space.builtin.get(space.str_w(gs__issubtype))), w_0, space.w_tuple)
[19:38] <stakkars> second call is similarand has error checking.
[19:38] idnar (mithrandi@idnar.user) left irc: Client Quit
[19:38] <arigo> ah
[19:40] <stakkars> I'm calling normalize_exception, then check for being an Exception, then a check against w_TypeEror is done.
[19:40] <stakkars> need to check if this is really ok.
[19:43] <stakkars> ahh HAAA
[19:44] <stakkars> if goto == 37:
[19:44] <stakkars> w_106 = space.issubtype(w_107, g2tuple)
[19:44] <stakkars> that's bad :-)
[19:44] <arigo> ouap
[19:44] <arigo> (today's IRC log will be hectic)
[19:44] <stakkars> directly in dir() block 37
[19:46] <stakkars> arghh
[19:54] <stakkars> waaah, I found it. It is here:
[19:54] <stakkars> for attr in ['__members__','__methods__']:
[19:54] <stakkars> try:
[19:54] <stakkars> for item in getattr(obj, attr):
[19:54] <stakkars> if isinstance(item, types.StringTypes):
[19:54] <stakkars> Dict[item] = None
[19:54] <stakkars> except (AttributeError, TypeError): pass
[19:54] <stakkars> the lastline translates into
[19:54] <stakkars> if goto == 37:
[19:54] <stakkars> w_106 = space.issubtype(w_107, g2tuple)
[19:55] <arigo> waah indeed
[19:55] <stakkars> where g2tuple is definedas
[19:55] <stakkars> g2tuple = space.newtuple([space.w_AttributeError, space.w_TypeError])
[19:57] dlk (~dlk@82.96.42.156) left irc: Read error: 145 (Connection timed out)
[19:57] <stakkars> and this is (fun, fun) nothing created in geninterp, but an inconsitency elsewhere (puuh)
[19:58] <stakkars> I think this comes to me as an operation, as is.
[19:58] <arigo> ah, it's wrong the flow graph already then
[19:59] <stakkars> jaaaaaa :)
[20:00] <stakkars> either space.issubtype must accepttuples, or the flow graph must unroll the tuple.
[20:02] <pedronis> the problem is that the flowspace does not sees the exception catching logic in space.match_exception
[20:03] <pedronis> exception_match I mean
[20:03] <arigo> argh
[20:04] <arigo> time to make exception_match() more explicit
[20:04] <arigo> instead of eating all OperationErrors at one point
[20:04] <stakkars> so far, pickle and geninterp seem to be my best bug-finders.
[20:04] <pedronis> well, then we will get problems with the annotator
[20:05] <stakkars> why not simplymake space.issubtypesmarter`
[20:05] <stakkars> ?
[20:06] <pedronis> I start to think that it would be saner if match_exception would appear as a macro operation in the graphs
[20:06] <arigo> good point
[20:06] <stakkars> sorry, have to go, leaving lots of checkins un-ckecked :(
[20:06] <arigo> actually, the graph should be a bit different even
[20:06] <arigo> stakkars: see you
[20:07] <arigo> the graphs should use their built-in exception-matching capabilities
[20:07] <stakkars> maybe later, thanks for all the help and bugs :)
[20:07] stakkars (~tismer@82.144.60.19) left irc: "bye"
[20:07] cfbolz (~cfbolz@hdlb-d9b95c20.pool.mediaWays.net) joined #pypy.
[20:08] <cfbolz> Hi!
[20:09] <cfbolz> I need a quick clarification about exception handling:
[20:10] <cfbolz> Is this correct: A spaceop produces an exception only if it is encased *directly* by a try:...except - block.
[20:10] <cfbolz> I am talking especially about ops for builtin types, I now that an explicit raise always raises the exception
[20:11] <arigo> yes if "directly" means "in the same function"
[20:12] <arigo> it's implemented by supposing that some well-known builtins always produce some well-known exceptions (there is a table) and then cutting off the exception branches that jump directly out of the function.
[20:13] <cfbolz> exactly. That's what I was getting at.
[20:14] <cfbolz> calling def f(lst, n): return lst[n] will never raise an exception, right?
[20:14] Action: arigo writes down a note to document this in controlflow.txt
[20:14] <arigo> yes, right
[20:15] <cfbolz> Ok. It's clear, when you think about it, otherwise you would have to have two version of f, one with, one without exceptions
[20:15] <arigo> yes
[20:15] <cfbolz> Thank you.
[20:16] <arigo> happy hacking :-) see you later
[20:17] <cfbolz> well, I'm quite happy right now. See you.
[20:17] <cfbolz> :-)
[20:18] cfbolz (~cfbolz@hdlb-d9b95c20.pool.mediaWays.net) left irc: "Verlassend"
[20:18] Action: pedronis also about to leave
[20:18] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "ChatZilla 0.9.61 [Mozilla rv:1.7.6/20050324]"
[20:20] arigo (~arigo@134.99.18.225) left irc: "[x]chat"
----- silence for 19 minutes ----- [20:39] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[20:41] pedronis (pedronis@ratthing-b246.strakt.com) left irc: Client Quit
[20:41] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[20:42] pedronis (pedronis@ratthing-b246.strakt.com) left irc: Client Quit
[20:56] idnar (mithrandi@idnar.user) joined #pypy.
----- silence for 19 minutes ----- [21:15] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) left irc: Read error: 148 (No route to host)
[21:18] dialtone (~dialtone@host111-56.pool80117.interbusiness.it) joined #pypy.
[21:27] idnar (mithrandi@idnar.user) left irc: Read error: 131 (Connection reset by peer)
[21:27] idnar (mithrandi@idnar.user) joined #pypy.
[21:40] lac (~lac@c-51c6e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy.
[21:46] pedronis (~Samuele_P@c-298b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 32 minutes ----- [22:18] pedronis (~Samuele_P@c-298b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Remote closed the connection
----- silence for 22 minutes ----- [22:40] idnar (mithrandi@idnar.user) left irc: Nick collision from services.
[22:40] idnar_ (mithrandi@idnar.user) joined #pypy.
----- silence for 17 minutes ----- [22:57] dlk (~dlk@82.96.42.156) joined #pypy.
[00:00] --- Tue Apr 5 2005