IRC log ======= :: [09:41] arigo: is it possible to ask the backendoptimizer to completely remove all the oogetfield('meta', obj)? [09:42] and at the same time to change all the oogetfield('somefield', meta) into oogetfield('somefield', obj) [09:42] because then we wouldn't need the metaclass hierarchy anymore [09:42] (at least in common lisp) [09:42] as far as I know the idea was indeed to be able to do this kind of things [09:43] but not necessarily in the existing backendopt [09:44] uhmmm [09:44] I have no idea how to do this stuff [09:44] if I understand it correctly, as a first step you can just tweak gencl to recognize oogetfield('meta', obj) [09:44] I'll think about it on the plane maybe [09:44] and produce a same_as equivalent instead [09:44] (do I make any sense at all?) [09:44] yes [09:45] same_as(meta, obj) [09:45] so that the next oogetfield() will still work on meta which in reality is the obj [09:45] yes [09:45] thus you obtained the same thing without removing anything [09:45] cool [09:46] dialtone: can you explain me better what are you trying to do? [09:46] it looks kinda simple [09:46] am I a fool? [09:46] antocuni: I want to get rid of the metaclass stuff in common lisp [09:47] since common lisp supports class variables [09:47] (DEFCLASS foo () ((bar :allocate :class))) [09:47] cool [09:47] but to do that I also have to get rid of the opcodes that work on the object model [09:48] at first I thought about removing the metaclass related operations (or change them) but armin got a great idea about using same_as [09:48] idnar (i=mithrand@unaffiliated/idnar) left irc: Remote closed the connection [09:48] there might be a few problems, though [09:48] and here comes the part I feared [09:48] I'm not sure if the meta object is used for more than oogetfields [09:49] and also, let's see if there are name clashes in the fields [09:49] I can't understand a thing: are you trying to lookup some fields in the obj directly, instead of in the metclass, right? [09:49] antocuni: yes [09:50] why an object should have fields that belongs to its metaclass? [09:50] arigo: uhmmm you can have both a class variable and an instance variable named in the same way? [09:50] metaclass is not a real metaclass [09:50] I don't know [09:50] arigo - r26566 - Support geterrno() from rctypes to genc. [09:50] dialtone: ah, now I understand [09:50] I would expect it not to be the case, as the names come from RPython names [09:51] arigo: indeed [09:51] but I guess I can set different accessors maybe for class level things and for instance level things [09:51] let's try [09:51] no... [09:52] so a name clash would break stuff [09:52] but... how do you recognize an access to a class variable and one to an instance variable from RPython? [09:53] dialtone: I think we don't have name clashes, because there is some mangling anyway [09:53] cool [09:53] if I see it correctly, class variable names start with 'pbc' and instance ones with 'o' [09:53] that's what we've done in gencl yes [09:54] ? that's what the ootyping is doing [09:54] yes yes [09:54] :-) [09:54] I mean that I see the distinction in gencl :) [09:54] sooooooo [09:55] if I have a getfield where the first argument is meta and I simply emit the same code that I emit for the same_as I should be safe removing all the meta stuff... maybe [09:55] seems like a tiny change in gencl [09:55] dialtone: in RPython, the annotator says that attributes are instance fields as soon as they are written to instances, otherwise they are class attributes [09:56] yes, it should work [09:56] Palats (n=Pierre@izumi.palats.com) left irc: Read error: 104 (Connection reset by peer) [09:56] unless of course metaclasses are used for something else than class variables [09:56] ideally, you should not look for the name 'meta' but for some other hint [09:57] I'm not completely at ease with the various levels of ootype [09:57] neither am I\ [09:57] all field names other than those defined by ootype (like "meta") will be mangled, so i guess checking for "meta" is good enough [09:57] and I also have to ignore the setfield opcode that deals with metaclasses [09:58] or make it a same_as as well [09:59] apparently, the meta instances are used as the ootype of RPython classes [10:00] so they can be manipulated by RPython code that passes classes around [10:01] I guess you can also pass classes around in CL, read attributes from them, and instantiate them [10:01] yes [10:01] so a saner approach might be to try to have gencl use CL classes instead of these meta instances [10:03] uhmmmmm [10:03] which means: recognize if an ootype.Instance is actually representing an RPython class (by using a hint) [10:03] I also have to deal with the Class_ [10:03] but that can probably be set to standard-class [10:03] yes, I think it's saner to make, basically, oogetfield('class_') be a same_as [10:04] cool [10:04] I think I'll save this irc log to put it in the svn tree for sanxiyn [10:04] to recognize RPython class represenations: if the ootype.Instance has the superclass ootypesystem.rclass.CLASSTYPE, then it's a "metaclass" [10:04] he is thinking about this in the plane (at least this is what he told) [10:05] :-) [10:05] nikh: yes [10:05] ootype is indeed rather complicated, level-wise, to support limited languages like Java [10:05] unfortunately, yes [10:05] well, in a way it's very convenient for the backends [10:05] but if you want to use more native constructs, it gets hairy quickly [10:05] I dunno [10:05] depends on the backend [10:06] hum, there is still an information missing that gencl would need here [10:06] I think if the language of the backend is powerful enough it could use an higher abstraction [10:07] dialtone: yes, there is also the (hairly to implement) idea of producing slightly different things for different back-ends too [10:07] using backendopts? [10:08] would it make sense to have a kind of backend_supports=['metaclasses', 'classvariables', 'first_class_functions'...] [10:08] maybe, but I was thinking about doing different things in ootypesystem/rclass already [10:08] yes, such a backend_supports would be great [10:09] dialtone: there is still an hour left to sprint, so go go go ;) [10:09] you can do it, if you want it ;) [10:09] what is missing is the link from the concrete Instance types, and which Instance corresponds to its meta-instance [10:10] idnar (i=mithrand@unaffiliated/idnar) joined #pypy. [10:10] dialtone: it's not as simple as making an oogetfield be a same_as [10:10] KnowledgeUnboundError, Missing documentation in slot brain [10:10] right now for CL the goal would be to generate for a normal Instance, a DEFCLASS whose :allocate :class attributes are the attributes of the meta-Instance [10:11] we could optionally have class fields in Instances, and then operations like ooget/setclassfield [10:11] the reason why I ask is that if we manage to do this then we could also use default Condition as Exception [10:11] and we could map the Conditions in common lisp to exceptions in python transparently [10:12] since the object systems will then match (and they are vaguely similar anyway) [10:12] nice [10:12] at least I think [10:18] I'm still rather confused by ootypesystem/rclass [10:18] although I think that blame would show my name on quite some bits :-) [10:19] there are no class attributes read through instances [10:19] they are turned into method calls [10:19] accessor methods [10:20] it's a bit organically grown [10:20] accessor methods were introduced at one point, and the meta-Instance later [10:21] uhmmm [10:22] what was the reason for having accessor methods? [10:22] they seem to be only generated for class vars that are overriden in subclasses. [10:22] yes [10:22] before we had the meta-Instance trick, it was the only way to avoid storing the value in all instances [10:22] aha [10:23] we could possibly get rid of these accessors [10:23] now, yes, by storing the values in the meta-Instance [10:23] they are alway anyway stored in the meta-Instance, I think [10:23] no, I think that other values are stored in the meta-Instance right now [10:24] it's the values that are only ever accessed with a syntax 'ClassName.attr', i.e. not through an instance [10:24] ...more precisely, with 'x = ClassName or OtherClassName; x.attr' [10:25] hm, i'm still trying to read this out of the code ... [10:28] it's in ClassRepr._setup_repr() [10:28] there is no clsfields here, just pbcfields [10:28] # attributes showing up in getattrs done on the class as a PBC [10:28] i see