[00:00] pedronis (~Samuele_P@c-178b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
[00:00] pedronis (~Samuele_P@c-178b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: Client Quit
[01:25] freakazoid (~seanl@pat100.wirelesssecuritycorp.com) joined #pypy.
[01:25] <freakazoid> anyone around?
----- silence for 18 minutes ----- [01:43] _hannes (~yuuhu@i3ED6B489.versanet.de) joined #pypy.
[01:43] yuuh (jbthtiv@i3ED6B489.versanet.de) left irc: Read error: 131 (Connection reset by peer)
[01:43] <freakazoid> hi _hannes
[01:48] <_hannes> heyho
[01:49] <freakazoid> how's it going?
[01:51] <freakazoid> I wanted to see if anyone thought my idea of making psyco ctypes-aware was worthwhile
[01:51] <freakazoid> basically replacing ctypes calls with direct function calls in any generated machine code
[01:53] <_hannes> :o
[01:54] <freakazoid> it would make it worthwhile to port modules that were "just wrapping C libraries" to Python using ctypes
[01:54] <freakazoid> then the type information would be available to psyco
----- silence for 55 minutes ----- [02:49] freakazoid (seanl@pat100.wirelesssecuritycorp.com) left #pypy.
----- silence for 4 hr and 57 minutes ----- [07:46] _hannes (~yuuhu@i3ED6B489.versanet.de) left irc: "utz utz utz"
----- silence for 24 minutes ----- [08:10] hpk (~hpk@merlinux.de) joined #pypy.
[08:21] adim (~adim@logilab.net2.nerim.net) joined #pypy.
----- silence for 20 minutes ----- [08:41] stakkars (vakqtj@i3ED6B489.versanet.de) left irc: Read error: 54 (Connection reset by peer)
----- silence for 1 hr and 56 minutes ----- [10:37] arigo (~arigo@134.99.112.244) joined #pypy.
----- silence for 1 hr ----- [11:37] cfbolz (~bolz@daq01.physi.uni-heidelberg.de) joined #pypy.
----- silence for 21 minutes ----- [11:58] <cfbolz> hi all!
[11:58] <cfbolz> How was the sprint?
[12:00] <arigo> hi!
[12:00] <arigo> nice to see you around here
[12:00] <arigo> the sprint was quite ok
[12:01] <arigo> mainly more details about CPython compliancy and completeness
[12:02] <arigo> plus a few C modules (parser, binascii, array soon) that have been integrated
[12:03] <arigo> btw, I will give your nice work on llvm a serious look soon,
[12:03] <arigo> as the next step is to decide which back-end we should focus on next for a complete translation of PyPy
[12:04] <cfbolz> thanks! genllvm got a bit messy the last few days
[12:04] <cfbolz> But I'l try to implement exceptions this weekend and clean it up afterwards
[12:05] <arigo> nice
[12:05] <cfbolz> It should be quite easy, the stack unrolling features in llvm look very good
[12:06] <cfbolz> something else: there is a llvm tool which does a llvm->C translation
[12:07] <cfbolz> so maybe some of llvm's problems get alleviated by that
[12:07] <cfbolz> (for example lack of support for many platforms)
[12:08] <arigo> interesting
[12:09] <cfbolz> has someone else managed to get llvm to run?
[12:09] <arigo> I think so, yes
[12:09] <arigo> basically if you hack a bit until it compiles, then your test seem to pass just fine
[12:10] <arigo> can you give us some more info about genllvm status?
[12:10] <arigo> the current situation is that genc.py more or less generates a complete translation of PyPy
[12:10] <arigo> but without using the type annotations at all
[12:11] <arigo> as I understand it, genllvm only translates fully annotated graphs
[12:11] <arigo> i.e. it fails on SomeObject() annotations
[12:11] <cfbolz> yes that's true
[12:12] <cfbolz> But i've been working on some type information things last weekend
[12:12] <cfbolz> I haven't thought about whether that helps with translating SomeObject's
[12:13] <arigo> do you think it be reasonably easy to add support for the generic PyObject* and link with CPython's API?
[12:13] <cfbolz> Either it is easy or a total nightmare :-)
[12:14] <arigo> :-)
[12:14] <cfbolz> I don't know the Python C-API well enough to test that thoroughly, though
[12:15] <arigo> basically we have to choose between enhancing genc.py to add typed objects (which can be done gradually)
[12:15] <arigo> or adding PyObject* support to another back-end that already nicely supports types
[12:16] <cfbolz> how much of pypy is annotated with SomeObjects?
[12:16] <arigo> I admit I'm a bit afraid of having to compile (and tell people to compile) LLVM everywhere
[12:16] <arigo> there isn't much SomeObjects left, but it's difficult to get rid of them all in the short term
[12:16] <cfbolz> Oh i see
[12:17] <cfbolz> For shipping a translated pypy the llvm->C thingy might help, too.
[12:17] <arigo> yes, that's a possibility
[12:17] <cfbolz> Though for a Psyco replacement that would not help.
[12:17] <arigo> :-)
[12:17] <cfbolz> :-)
[12:18] <arigo> there is another issue: we're not sure how portable a translated pypy would be
[12:18] <cfbolz> True
[12:18] <arigo> right now, the translation process "freezes" some os module constants into the result, for example
[12:19] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[12:19] <cfbolz> Ok. Something like that would probably not be covered by llvm->C
[12:19] <arigo> hi samuele
[12:19] <pedronis> hi
[12:19] <cfbolz> arigo: What sort of operations SomeObjects need to support?
[12:20] <cfbolz> Oops, a "would" is missing.
[12:20] <arigo> most operations, I'm afraid
[12:20] <cfbolz> So I would need to mirror CPython memory layout.
[12:20] <arigo> for PyObject*, I think there is no other way in the short term, yes
[12:22] <cfbolz> What a pity :-)
[12:23] <arigo> indeed
[12:23] <cfbolz> What sorts of things are annotated to SomeObject?
[12:23] <arigo> faked stuff
[12:23] <arigo> file, long, unicode
[12:23] <cfbolz> Ah
[12:24] <cfbolz> But a low level implementation is needed for those anyway, right?
[12:24] <arigo> at some point yes
[12:24] <arigo> there might be intermediate solutions in which we write a "semi-fake" low-level implementation
[12:25] <arigo> in which the remaining SomeObjects basically only have to support method calls
[12:25] <arigo> calls to statically known methods.
[12:25] <cfbolz> Which would be quite a lot easier
[12:26] <arigo> yes, though there is still some amount of messiness around the corner
[12:26] <cfbolz> Right
[12:26] <arigo> e.g. the arguments and return value of the method call need to be converted between LLVM types and regular PyObject* and back
[12:26] <arigo> which is quite messy for mutable arguments
[12:27] <pedronis> hpk: ?
[12:29] <arigo> I can't think of an example of faked low-level method that would mutate its arguments, but I'm probably overlooking one
[12:29] <cfbolz> Ok, that might help
[12:30] <arigo> if there is none, we could use a simplified interface to CPython in which the arguments can only be either PyObject* directly or some basic primitive types
[12:30] <cfbolz> Ok
[12:31] <cfbolz> If I understand it correctly:
[12:31] <cfbolz> It would be wasteful to mirror CPython's memory structure
[12:31] <cfbolz> since an translated Pypy object holds some bits of data twice
[12:32] <cfbolz> if it is done that way
[12:33] <arigo> yes, either twice or only once but in CPython's layout which doesn't benefit from type knowledge
[12:33] <arigo> e.g. a PyListObject holding pointers to PyIntObjects instead of just an array of ints
[12:33] <cfbolz> Ok
[12:33] <cfbolz> So in the end that's not what we want
[12:34] <arigo> yes, apart from faked objects, which would be a black-box pointer from the translated code's point of view
[12:34] <cfbolz> yeah, but not for a 'nice' object
[12:35] <arigo> indeed, but for black boxes we should check how many operations and auto-conversions we need to implement
[12:36] <cfbolz> Right. Maybe it is only a very limited number of operations
[12:36] <arigo> that's the difficult bit: if there are few of them, then genllvm (or possibly another gen*) might be a good starting point; if there are many of them, then genc.py is better because it already knows about *all* operations on black boxes
[12:36] <cfbolz> right
[12:36] <cfbolz> In genc the result is always working
[12:37] <cfbolz> in genllvm the result is not working till the but always 'good'
[12:37] <cfbolz> 'end' missing.
[12:37] <cfbolz> oops
[12:37] <arigo> yes
[12:38] <arigo> genc has definitely the "incremental testing" advantage...
[12:38] <cfbolz> right
[12:38] <cfbolz> Can you think of any bits of pypy that does not use SomeObjects?
[12:39] <arigo> yes, there are large parts without SomeObject
[12:39] <arigo> type inference works quite well, actually
[12:39] <cfbolz> At the moment I'm only testing genllvm with little made up functions and I would really like to throw it at some bigger piece of "real life" code
[12:40] <arigo> :-)
[12:40] <cfbolz> :-)
[12:40] <arigo> there is goal/translate_pypy0.py that does half of PyPy mostly completely
[12:40] <arigo> only mostly, though
[12:41] <cfbolz> But genllvm needs more work before I try that anyway
[12:41] <cfbolz> For example: I have not started dicts
[12:41] <cfbolz> And I'll probably need help for that
[12:41] <cfbolz> I have no idea how opimized the dict implementation will have to be
[12:42] <arigo> that's a good question
[12:42] <cfbolz> Thought so :-)
[12:43] <arigo> we need string-key-only dicts that should be optimized for reading (ok if modifying them is slow)
[12:44] <cfbolz> Ok
[12:44] <arigo> I'm supposed to write a summary of the options for "what we should do next"
[12:45] <cfbolz> Well, who doesn't want to know that? :-)
[12:46] <cfbolz> For my part, I think I'll polish the translation of annotated flow graphs a bit more (e.g. exceptions, maybe dicts)
[12:46] <cfbolz> Afterwards I have to give the SomeObject issue more thought
[12:47] <cfbolz> I'll have an exam on Thursday (linear algebra) but I should be able to work on PyPy full time next week
[12:47] <arigo> nice
[12:48] <cfbolz> So we'll see where this gets me :-)
[12:48] <arigo> :-)
[12:48] <cfbolz> Oh one other thing: how much mutiple inheritance is really needed?
[12:48] <arigo> not much
[12:49] <arigo> only "mixin-style" multiple inheritance
[12:49] <cfbolz> So no common base classes?
[12:49] <arigo> no
[12:49] <cfbolz> what a relief
[12:49] <arigo> :-)
[12:50] <arigo> in fact, only class X(Y, Z1,..,Zn)
[12:50] <arigo> where Z1...Zn are all classes with no further bases and with the '_mixin_' attribute set to True
[12:50] <cfbolz> ok
[12:51] <arigo> and it's basically ok to copy all the attributes from Z1...Zn into X, i.e. there is no 'isinstance(x, Z1)' check being performed
[12:51] <cfbolz> That's perfect
[12:51] <pedronis> I there's an of an execption with Exception somewhere which should be special cased
[12:52] <cfbolz> Ok, but exceptions need to be special cased a bit, anyway
[12:53] <arigo> pedronis: we discussed about how much operations the residual SomeObjects need to support in genllvm
[12:53] <pedronis> I'm following
[12:54] <arigo> does it seem possible to reach a state where SomeObjects are only used with method calls taking simple arguments?
[12:54] <pedronis> we probably know only after we got to annotate the std object space + modules
[12:55] <arigo> ok
[12:55] <pedronis> maybe, I think faking right now
[12:55] <pedronis> is e.g. wrapping and unwrapping lists in some cases
[12:56] <arigo> ah ha
[12:56] <arigo> but unwrapping a list creates a fresh list, so apparently there is no mutation that needs to be rewrapped
[12:56] <arigo> (otherwise we'd have run into bugs)
[12:58] <arigo> in fact, it seems that the types that can be unwrapped right now are precisely the ones that need to be supported as arguments to faked method calls
[12:59] <arigo> if so, that's not too many, and never in a mutating way
[13:00] Nick change: pedronis -> pedronis_afk
[13:00] Action: arigo -> lunch
[13:02] Action: cfbolz --> lunch, too
[13:02] arigo (~arigo@134.99.112.244) left irc: "[x]chat"
----- silence for 18 minutes ----- [13:20] Nick change: pedronis_afk -> pedronis
----- silence for 25 minutes ----- [13:45] Action: cfbolz <-- back
----- silence for 26 minutes ----- [14:11] <cfbolz> is it possible that pypy-svn doesn't work?
[14:14] <pedronis> yes
[14:14] <pedronis> I sent a mail to hpk
[14:18] <cfbolz> ok. I just wondered what happened to my checkin yesterday but I just don't seem to have gotten mail
----- silence for 26 minutes ----- [14:44] cfbolz (~bolz@daq01.physi.uni-heidelberg.de) left irc: "Leaving"
[14:55] arigo (~arigo@134.99.112.244) joined #pypy.
[15:01] stakkars (qxczgdcd@i3ED6B489.versanet.de) joined #pypy.
----- silence for 16 minutes ----- [15:17] <jacob22> I've gotten information from Andy concerning Oxford. Unfortunately he can't get us free space. He has an option for 45 pounds/day at a 5 minute bus ride from the town centre, and one for 160 pounds per day at the Randolph Hotel smack in the middle of town.
[15:18] <stakkars> hi all! Jetlag gone?
[15:18] <jacob22> stakkars: Not completely. But I woke up at 10 today without using the alarm clock.
[15:19] <stakkars> whow!Yesterday I woke up at 8:00, but DC time :-) Today was much better.
[15:20] <jacob22> So, we should decide what to do about the Oxford sprint. Run it as planned, shorten it, cancel?
[15:21] <stakkars> jacob22: when would Oxford be, again?
[15:22] <jacob22> 24-30 April
[15:23] <stakkars> fine. Not coinciding with my mother's birthday on the 13th.
[15:24] <arigo> hum, I woke up at 3am local time, which appears not to be a reasonable time for DC either
[15:25] <jacob22> arigo: No, that is unreasonable in both timezones. ;-)
[15:25] <arigo> :-)
[15:26] <stakkars> I remember I had that too, on other US journeys. Going to bed too early mixes everything up.
[15:26] <stakkars> arigo: I got a small but nasty problem.
[15:27] <jacob22> The cheaper venue has a webpage: http://www.the-oxford-centre.co.uk/
[15:27] <stakkars> nice. is the girl included?
[15:29] <jacob22> I'm sure she costs extra.
[15:29] <stakkars> :-)
[15:29] <stakkars> jacob22: how is the price of the place a problem? Even 160 punds per day makes for 16 pounds per person,
[15:30] <stakkars> which is still much less than the hotel costs.
[15:30] <arigo> reasonable enough
[15:30] <stakkars> what I wanted to say: would these costs make it unfeasible to have the sprint?
[15:32] <stakkars> arigo: I'm working on translating all the applevel calls into interp-level.
[15:32] <stakkars> arigo: but what bites me is the fact that by that, I get tons of dependencies at import time.
[15:32] <jacob22> No, I just want to have agreement on what to do. Also, we haven't agreed on how to divide costs for sprinting venues. Per partner, per partner person attending, or some other way...
[15:33] <arigo> I guess it's a question for pypy-funding
[15:33] <stakkars> jacob22: ok. My suggestion would be divided by percentage of funding per partner.
[15:33] <arigo> and/or pypy-dev, about confirming the sprint
[15:34] <stakkars> arigo:now I have splitted four or five modules into two and changed all the imports, to allow
[15:35] <stakkars> an early run of flow space, but still I get hit by the fact that specialcase wantsto import pyframe.
[15:35] <mwh> arigo: weakref.proxy's nb_int is broken too, i think
[15:35] <mwh> well, very slightly
[15:36] <stakkars> do you think I should continue this way, or do something special about import in this case?
[15:36] <mwh> hmm
[15:36] <stakkars> I can let applevel grab the current sys.modules and fake some for the flowspace, which would avoid recursion,
[15:37] <stakkars> at the cost of duplicate imports, justfor the flowing process.
[15:37] <jacob22> stakkars: I can see partners who do not participate in the sprint resenting such an arrangement. However, we can put the issue to the whole group.
[15:37] <arigo> bootstrapping fun
[15:38] <stakkars> arigo: note that pypy-funding is stillnot working. We need to builda parallel service!
[15:38] <stakkars> arigo: do you prefer a nice hack over splitting so many modules?
[15:39] <arigo> mwh: are you thinking about str->nb_int which shouldn't be there?
[15:39] <mwh> no, not quite
[15:39] <mwh> i'm thinking of bug #1075356
[15:40] <arigo> it's true that proxy_int would incorrectly allow conversion to int from a weakref to a buffer object
[15:41] <stakkars> jacob22: I see. Actually I think that all partners should participate in all sprints
[15:41] <arigo> mwh: ah, you can take a weakref to a unicode subclass. You can't to a str subclass.
[15:46] <stakkars> arigo: I'm undoing the splits now and trying the sys.modules trick. Having to allow early imports offlow space all the time would put larger impacts on all the code, which should be avoided.
[15:48] <mwh> arigo: yes
[15:50] <arigo> stakkars: I still don't completely understand what's going on
[15:51] <stakkars> arigo: tried to replace gateway.applevel by gateway.applevelinterp.
[15:51] <jacob22> stakkars: I agree, but I don't think there is general agreement about that.
[15:51] <stakkars> instead of faking applevel code, this runs geninterplevel on the code and behaves similar.
[15:52] <stakkars> the problem is, that geninterp enforces imports of pyopcode,pyframe and much more at a time where these
[15:52] <stakkars> stilldon't exist, and applevel is used in very deep, earlymodules.
[15:53] <stakkars> That means I cannot use geninterp directly, because it is called recursively in the first place from modules,
[15:53] <stakkars> which it needs to import itself.
[15:54] <stakkars> jacob22: Let's talk about it. I don't see why partners with a special, later topic should not be helping with the ground work.
[15:55] <arigo> stakkars: geninterp should be called only when the source code is actually needed, not when it is built
[15:56] <stakkars> arigo: hpk asked for a drop-in replacement for applevel that does the translation instead of running applevel.
[15:57] <stakkars> of course this wilol needto run only when the code changes, but I need to do it once.
[15:58] <arigo> I mean that geninterp can be called from the _builddict() method, not from __init__()
[15:59] <stakkars> you mean I would not compile immediately, but build a list of source that will be built after bootstrapping?
[16:00] <arigo> yes. do as little as possible in __init__(), and everything in _builtdict() or _buildcode().
[16:04] <stakkars> oh, now I see it. I did things too early, and so I don't get laziness. Now I understand.
[16:05] <arigo> :-)
[16:07] <stakkars> nicht verzagen, Rigo fragen
----- silence for 53 minutes ----- [17:00] _hannes (xvxcyid@i3ED6B1F1.versanet.de) joined #pypy.
[17:08] stakkars (qxczgdcd@i3ED6B489.versanet.de) left irc: Read error: 60 (Operation timed out)
[17:23] sanxiyn (tinuviel@222.233.187.78) joined #pypy.
[17:28] stakkars (cgyasps@i3ED6B1F1.versanet.de) joined #pypy.
[17:29] <sanxiyn> New pure Python TimSort rocks. It seems it's actually fast!
[17:29] <stakkars> he hoo, found a bug in app_descriptor.py -- Raimond's code is not quite correct
[17:29] <arigo> sanxiyn: :-)
[17:29] <arigo> stakkars: :-(
[17:30] <stakkars> __doc__ lets geninterp screw up, because it is a slot, which is bad.
[17:30] <arigo> slotification of app_descriptor.py is entierely my fault
[17:30] <stakkars> there must be a class doc,different from an instance doc
[17:30] <arigo> argh
[17:31] <stakkars> ok, then arigo.blame.append(Raimond.blame.pop())
[17:31] <arigo> btw can you answer the question # XXX why: or "" ?
[17:32] <stakkars> yes. It is just wrong, ought to be None not ""
[17:32] <arigo> ok
[17:32] <stakkars> I guess this is again a prototype, no longer compatible to the C version.
[17:32] <arigo> lemme fix __doc__ to be a slot and a class-level string at the same time...
[17:33] <stakkars> just givin it a different slot name should be fine. Also,allowing __doc__ as a slot on a class seems to be wrong in Python.
[17:34] <stakkars> This breaks the distinction between class attributes and instance attributes implemented by class properties.
[17:34] <arigo> but property(..., "hello").__doc__ == "hello"
[17:35] <stakkars> yes, true. So the slot needs to figure out whether it is boundor not.
[17:35] <arigo> but in CPython it doesn't work that way:
[17:36] <stakkars> just wading through it...
[17:36] <arigo> property.__dict__['__doc__'] => <member '__doc__' of 'property' object>
[17:36] <arigo> i.e. the __doc__ is indeed a slot in the class
[17:36] <stakkars> ok!!
[17:36] <arigo> but the metaclass type(property) comes into play!
[17:36] <arigo> waaa
[17:36] <stakkars> I see, yes it is crazy.
[17:37] <arigo> type.__dict__['__doc__'] => <attribute '__doc__' of 'type' objects>
[17:37] <arigo> attribute '__doc__' of 'type' objects is not writable
[17:38] <sanxiyn> Crazy indeed.
[17:39] <arigo> lemme understand what PyPy is doing right now...
[17:39] <arigo> type.__doc__
[17:39] <arigo> <GetSetProperty object>
[17:39] <stakkars> versus CPython's correctly displayed __doc__ string of type :-)
[17:43] <stakkars> type_get_doc first returns tp->tp_doc for heaptypes, then looks into tp_dict, then tries to use tp_descr_get if it is such a beast, otherwise returns the result directly.
[17:43] <arigo> !
[17:45] <arigo> it returns tp->tp_doc for NON-heap types, right?
[17:45] <stakkars> yessir!
[17:46] <arigo> crazy stuff
[17:46] <stakkars> that's why type.__doc__ is returned corretcly
[17:46] <stakkars> on instances, __doc__ is read/write?
[17:47] <arigo> wait a minute
[17:47] <stakkars> if so, the distinction lies in using the correct descr thing
[17:48] <arigo> in which extremely convoluted case do we need to do the ".__get__(None, t)" part?
[17:48] <arigo> __doc__ specified as a class property??
[17:48] <stakkars> I guess so. Where is that part in typeobject.c if at all?
[17:49] <arigo> in type_get_doc, the tp_descr_get() bit
[17:50] <arigo> argh argh argh
[17:51] <stakkars> :-D
[17:51] <arigo> in CPython you can't just define class X(object):
[17:51] <arigo> with both a docstring and a __doc__ slot
[17:51] <arigo> and expect it to work
[17:51] <arigo> X().__doc__ returns the same as X.__doc__, i.e. the docstring
[17:51] <arigo> and X().__doc__ is read-only too
[17:51] <arigo> in other words the __doc__ slot is ignored
[17:51] <stakkars> grumpfft
[17:52] <stakkars> how the hack does it work, then.
[17:52] <arigo> in CPython it works because property is not a heap type
[17:52] <arigo> I think
[17:52] <stakkars> that was exactly what I was about to type :)
[17:53] <stakkars> then the backdoor solution is to do exactly that.
[17:53] <stakkars> we already considered to silently make applevel defs into non-heaptypes
[17:53] <stakkars> but the problem remains, when I try to flow this crap, since we are in CPython.
[17:54] <stakkars> maybe it needs a getattribute hack...
[17:55] <stakkars> or I write a little extension module that mimicks this for CPython
[17:56] <arigo> wait a minute
[17:56] <stakkars> (o)
[17:56] <hpk> hi all
[17:57] <arigo> hi!
[17:57] <hpk> in addition to jet-lags i got stomach-ill ...
[17:57] <hpk> but it is getting all better now i hope
[17:58] <arigo> :-(
[17:58] <hpk> but i see you are already having fun again
[17:59] <hpk> the server should work again since saturday (although i only noticed today that the mailing lists weren'T properly started)
[17:59] <stakkars> hi! Yes,no mailman, but svn works
[17:59] <arigo> thanks!
[17:59] <arigo> ...did you know that 5 .__doc__ works?
[18:00] <stakkars> yes
[18:00] <arigo> ok
[18:00] <stakkars> especially boring in PyWin, the object browser always teaches me about ints :-)
[18:02] <arigo> ok, so I guess there is no sane way to have a __doc__ slot in CPython
[18:02] <stakkars> well, look at this example,please:
[18:03] <stakkars> nope, forgot to use (object). Ok, it is impossible.
[18:05] <stakkars> maybe a metaclass trick could do it?
[18:07] <arigo> or something more insane:
[18:07] <arigo> >>> class mydoc(object):
[18:07] <arigo> ... def __get__(self, x, y):
[18:07] <arigo> ... if x is None:
[18:07] <arigo> ... return "class doc"
[18:07] <arigo> ... else:
[18:07] <arigo> ... return docslot.__get__(x)
[18:07] <arigo> ...
[18:07] <arigo> >>> class X(object):
[18:07] <arigo> ... __slots__ = ['docslot']
[18:07] <arigo> ... __doc__ = mydoc()
[18:07] <arigo> ...
[18:07] <arigo> >>> docslot = X.docslot
[18:07] <arigo> x = X()
[18:07] <arigo> docslot.__set__(x, 'instance doc')
[18:07] <arigo> x.__doc__ == 'instance doc'
[18:07] <arigo> X.__doc__ == 'class doc'
[18:08] <stakkars> would C.__doc__ be returned as a callable, then? Or would it be automatically called?
[18:09] <arigo> ?
[18:10] <sanxiyn> It seems that mailman works too now. Thanks hpk.
[18:10] <hpk> sanxiyn: yes, since a couple of hours actually
[18:10] <hpk> sorry for all the inconvenience
[18:11] <hpk> it was a very very unfortunate chain of events that led to the outage
[18:16] adim (adim@logilab.net2.nerim.net) left #pypy.
[18:17] <stakkars> arigo: I don't get your exampleto work
[18:18] <arigo> ah?
[18:18] <arigo> it's copy-pasted from a working session
[18:18] <stakkars> sorry,forgot the __set__, works now :-)
[18:18] <stakkars> not that I understand it...
[18:19] <stakkars> ahh, I do. It uses the tp_descr_get branch,ok.
[18:20] <arigo> next job is to make it work in PyPy...
[18:20] <arigo> I still don't understand how 5 .__doc__ works in CPython
[18:21] <stakkars> give me a minute, too... (o)
[18:21] <arigo> ah I see now
[18:21] <arigo> in Python 2.1, it didn't work
[18:21] <arigo> it looks like an unexpected side effect
[18:22] <hpk> the 5 .__doc__ looks rather accidental
[18:22] <arigo> indeed
[18:22] <sanxiyn> Also ''.__doc__, etc.
[18:23] <arigo> the reason it works is because PyType_Ready() copies tp_doc to tp_dict['__doc__'] if there is no such key already
[18:23] <stakkars> yes!
[18:23] <arigo> it's rather strange
[18:23] <arigo> you'd expect the type_get_doc() accessor to do the right thing already for expressions like 'int.__doc__'
[18:27] <sanxiyn> I'd like to start some gossip, if you don't mind.
[18:27] <arigo> :-)
[18:28] <sanxiyn> I have an ingrown toenail. I got an excision last saturday.
[18:28] <sanxiyn> It hurts.
[18:29] <arigo> :-(
[18:29] <sanxiyn> In the company, we've finished a project -- domain management system.
[18:29] <stakkars> sanxiyn: think about __doc__ as a type slot. Then the pain moves elsewhere :-/
[18:30] <sanxiyn> And I got an one day break tomorrow. Good.
[18:30] <hpk> sanxiyn: domain as in XEN domain by any chanceß?
[18:30] <sanxiyn> hpk: ?
[18:30] <sanxiyn> hpk: DNS.
[18:31] <hpk> ah ok
[18:31] <sanxiyn> (I wrote the named.conf parser. Also some Twisted usage...)
[18:31] <sanxiyn> Also I have learned a lot (well, more than I wanted) about RRDtool.
[18:32] <sanxiyn> In other news, I got my first Debian package in the official archive Monday.
[18:32] <sanxiyn> simpleparse_2.0.0-3_i386.changes ACCEPTED
[18:33] <sanxiyn> Thank you for your contribution to Debian.
[18:33] <hpk> congrats
[18:33] <arigo> yep
[18:33] <stakkars> here too
[18:34] <sanxiyn> Thanks everybody...
[18:34] <hpk> but you didn't come to Pycon but should have :-)
[18:34] <sanxiyn> Well, my named.conf parser (and zone file parser) is written in SimpleParse. That explains the motivation, no? :-)
[18:34] <sanxiyn> hpk: Sadly.
[18:34] <stakkars> 1 .__doc__ does the following:
[18:35] <stakkars> tp_getattro, PyObject_GenericGetAttr,
[18:36] <stakkars> inlined _PyType_ lookup,
[18:36] <stakkars> finds type, gets tp_dict,
[18:37] <stakkars> has descr and asks PyType_HasFeature(descr->ob_type, Py_TPFLAGS_HAVE_CLASS)) {
[18:37] <stakkars> f = descr->ob_type->tp_descr_get;
[18:38] <stakkars> finds that PyDescr_IsData(descr) is false,
[18:38] <pedronis> arigo: unrelated, I saw you checked in a disabled test about annotating recursive lists, did you
[18:38] <stakkars> returns the descr
[18:39] <pedronis> arigo: thought about how to hanndle that
[18:40] <stakkars> finally, this descr was the doc string itself.
[18:41] <arigo> pedronis: half-heartedly
[18:41] <arigo> I'm not yet 100% sure we need that
[18:41] <arigo> I guess the parser module does need it
[18:42] <arigo> to handle it I can see a hackish and a cleaner-but-larger-changes path
[18:42] <stakkars> if a list contains itself, doesn't this raher imply that it is turned into SomeObject?
[18:42] <arigo> the hackish way is to detect somehow that a SomeList with the same factory is indirectly used as s_item of SomeList
[18:43] <arigo> stakkars: the goal is to obtain the annotation 's', where s = SomeList(s_item = s)
[18:43] <pedronis> arigo: doable, but messy indeed
[18:43] <arigo> the cleaner solution is to get rid of list factories, just like we got rid of instance factories
[18:43] <stakkars> ah
[18:44] <arigo> and have only SomeList(listdef=...)
[18:44] <arigo> with one ListDef per creation point
[18:44] <arigo> which records all places that read the s_item
[18:45] <arigo> i.e. consider lists as instances of an almost normal class, specialized by call site
[18:45] <pedronis> well, given previous experience I would go for the clean solution if we really need this
[18:45] <arigo> I guess so
[18:45] <stakkars> arigo: I could use a working property class very well, right now. Shall I use your hack, or will You do it?
[18:45] <arigo> stakkars: I just checked it in
[18:46] <stakkars> (k)
[18:47] <arigo> pedronis: I guess we should have a clean specialization mecanism for classes first
[18:47] <arigo> one that allows several call sites to be regrouped
[18:48] <arigo> i.e. if we see that two paths x=X() and y=X() merge, then the specialized classes X1 and X2 should be given a common specialized base class X3
[18:48] <hpk> stakkars: just a side note, i never "asked for" applevelinterp but indeed thought (and think) it's a worthwhile idea ...
[18:53] <stakkars> hpk: I don't see the point why you are coming back to such details again and again. The fact is that it is perfectly useful, and that's a request for me.
[18:55] <sanxiyn> I think some people just feel obliged to say so.
[18:56] <pedronis> arigo: I see
[19:01] <stakkars> gargll. Now I'm in an infinite recursion in gfunc_propertydoc___get__ :-D
[19:01] <stakkars> will try to nail that down...
[19:02] <arigo> ouap
[19:02] <arigo> of course this class property is not RPython-izable
[19:02] <arigo> I think
[19:02] <stakkars> gulp
[19:03] <arigo> or maybe it is
[19:03] <arigo> but caaaaaarefully
[19:03] <stakkars> I would really love it to be, in order to get rid of all stuff that is applevel
[19:04] <stakkars> or we need to support NOT_RPYTHON docstrings in gateway.applevel :-)
[19:05] idnar (mithrandi@idnar.user) joined #pypy.
[19:06] <arigo> gotta go, see you later possibly
[19:06] <stakkars> :(
[19:06] <hpk> is getting rid of applevel neccessary for getting a self-contained pypy?
[19:06] <arigo> yes yes I know sorry :-)
[19:06] <arigo> hpk: no
[19:06] Action: arigo don't think so
[19:06] <stakkars> no, but towards annotatable code it is very worthwile
[19:06] <pedronis> it may makes sense for some future targets
[19:07] <pedronis> right now it may mean some speedups
[19:07] arigo (~arigo@134.99.112.244) left irc: Remote closed the connection
[19:07] <stakkars> and as a side effect, translatability is a criteria to reallybe applevelRPython.
[19:12] <stakkars> hmm, D:\pypy\dist\pypy\tool\tb_server\server.py is not cross-platform.
[19:12] <stakkars> how do I emulate signal.pause() on Winnows?
[19:16] <pedronis> is time.sleep enough
[19:17] <stakkars> pedronis: probably
[19:18] <stakkars> on infinite recursion:
[19:18] <stakkars> It is not primarily about property.__doc__, but happens asa bad
[19:19] <stakkars> side effect of flow space's "self.setup_executioncontext(ec)"
[19:20] <stakkars> which enforces instantiation of "pyframe.normalize_exception.get_function(space)"
[19:20] <stakkars> which then calls into geninterplevel, again!!!
[19:22] <stakkars> that means, flow space enforces this to be run at true applevel, so far.
[19:22] <pedronis> ah
[19:23] <stakkars> so the laziness is not enough, here. I would need to have a placeholder instead of the real function.
[19:23] <stakkars> I can work around it by tracking the code being translated and falling back to applevel on recursion...
[19:25] <pedronis> it is probably saner to add hooks such that you can control the special cases
[19:31] sanxiyn (tinuviel@222.233.187.78) left irc: "Bye"
[19:33] <stakkars> pedronis: to add hooks to where?
[19:34] <pedronis> well, one possibility would be to move normalize_exception to the baseobjspace with a default impl that calls what now lives in pyframe
[19:36] <stakkars> but that doesn't change the fact that normalize_exception is applevel.
[19:37] <stakkars> You mean, flow space would then not enforce instantiation?
[19:37] <pedronis> yes, it would have another way to override it
[19:37] <pedronis> it is sort of nice that all the special cases go through call right now
[19:38] <pedronis> but is also somehow very implementatation dependent
[19:38] <stakkars> I guess I simply need one more level of indirection, and hook flowspace on the indirector instead of the real one.
[19:38] <pedronis> if normalize_exception would be written at interp-level
[19:38] <pedronis> we would need a special way to special case it
[19:38] <stakkars> (which is what I'm trying to generate...)
[19:39] <stakkars> yes but this is no problem, then, since it would statically exist.
[19:40] <stakkars> I can simply add a normalize_exception that calls a hook, which is the realone.
[19:40] <pedronis> I'm leaving the office now
[19:41] <stakkars> please wait
[19:41] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "ChatZilla 0.9.61 [Mozilla rv:1.7.3/20041007]"
[19:41] pedronis (pedronis@ratthing-b246.strakt.com) joined #pypy.
[19:41] <pedronis> back
[19:41] <stakkars> sorry. Please just give me advice how to do it, I need it to carry on.
[19:42] <stakkars> I add a normalize_exception to baseobjspace?
[19:42] <stakkars> the one in pyframe is renamed to something which gets called by default
[19:42] <pedronis> yes
[19:43] <stakkars> flow spacegets a different method, and it gets away from specialcase?
[19:43] <pedronis> and the flow space attach is own thing
[19:43] <pedronis> yes, it is a bit messier than everything going through call
[19:44] <pedronis> but is probably saner given your problems
[19:44] <pedronis> maybe Armin would like another solution, but this can allow you to go a bit further
[19:44] <stakkars> ok,but I also could rename normalize_exception to something and add a function that calls it. Less clean?
[19:45] <pedronis> well, one good thing about going through the space is that it is harder to mess up than with hooking into globals things
[19:45] <stakkars> I guess he would not like norm_except to be exposed as a pseudo usable property of spaces?
[19:46] <stakkars> it is a very low-leveldetail that should be hidden I think
[19:47] <pedronis> well, it could be called _norm_except <wink>
[19:48] <stakkars> ok,so I go for it, or do the simpler thing and wait for complaints? (then you may go home :-D )
[19:49] <pedronis> well, I'm going home now, I'm not feeling 100% today, a bit of cold
[19:49] <stakkars> same here, and my family is suffering fromflu as well. All the best to you!
[19:50] <stakkars> will try _norm_except
[19:50] <pedronis> all the best there too
[19:50] pedronis (pedronis@ratthing-b246.strakt.com) left irc: "ChatZilla 0.9.61 [Mozilla rv:1.7.3/20041007]"
[19:52] lac (~lac@c-51c6e055.1321-1-64736c11.cust.bredbandsbolaget.se) joined #pypy.
[20:04] _hannes (xvxcyid@i3ED6B1F1.versanet.de) left irc: Read error: 104 (Connection reset by peer)
----- silence for 37 minutes ----- [20:41] pedronis (~Samuele_P@c-178b70d5.022-54-67626719.cust.bredbandsbolaget.se) joined #pypy.
----- silence for 26 minutes ----- [21:07] <stakkars> pedronis: is moving the definition of normalize_exception directly into baseobjspace ok to do?
[21:09] <pedronis> I don't know
[21:11] <stakkars> doesn't work, gives cyclic imports, again :-(
[21:13] <stakkars> doing a simpler hack for now...
----- silence for 2 hr and 7 minutes ----- [23:20] jriehl (~jriehl@sidewinder.cs.uchicago.edu) joined #pypy.
[23:30] freakazoid (~seanl@pat100.wirelesssecuritycorp.com) joined #pypy.
[23:30] <freakazoid> hi
----- silence for 24 minutes ----- [23:54] pedronis (~Samuele_P@c-178b70d5.022-54-67626719.cust.bredbandsbolaget.se) left irc: "Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041107]"
[00:00] --- Wed Mar 30 2005