Rtyping classes definitions?
Hi, I'm writing the code that generates CLI classes starting from ootypesystem classes definitions, but as always I have a problem :-). At the moment the only way to access class definitions is by calling TranslationContext.annotator.getuserclassdefinitions(), which returns a list of ClassDef instances: I've noticed that class attributes are not typed but only annotated. Obviously for generating CLI classes I need to rtype class definitions, so that I can know the exact low-level type of the fields: I wondered if the absence of the rtyping step is intended or if it is a thing to do. In the latter case I could try to do it (hoping to do better than with rlist :-). ciao Anto
Hi Antonio Antonio Cuni wrote:
At the moment the only way to access class definitions is by calling TranslationContext.annotator.getuserclassdefinitions(), which returns a list of ClassDef instances: I've noticed that class attributes are not typed but only annotated.
Obviously for generating CLI classes I need to rtype class definitions, so that I can know the exact low-level type of the fields: I wondered if the absence of the rtyping step is intended or if it is a thing to do. In the latter case I could try to do it (hoping to do better than with rlist :-).
There must be a misunderstanding here, the rtyping step is not at all missing. ;) If you look at rtyped graphs you'll see that instances (and classes) have low-level types of the ootype.Instance kind. These Instance types have a _field attribute that is a dict mapping field names to their low-level types. You should be operating with these Instance types not with ClassDefs, the latter are mostly an implementation detail of the annotation phase. Cheers Nik
Hi Niklaus, Niklaus Haldimann wrote:
There must be a misunderstanding here, the rtyping step is not at all missing. ;) If you look at rtyped graphs you'll see that instances (and classes) have low-level types of the ootype.Instance kind. These Instance types have a _field attribute that is a dict mapping field names to their low-level types. You should be operating with these Instance types not with ClassDefs, the latter are mostly an implementation detail of the annotation phase.
Yes, there was a misunderstanding :-). I was searching for something containing the list of classes to be rendered, but now I've understood that I should collect informations about classes as long as I generate the code, that is the way gensqueak works (I was looking at your sources just now). Thanks a lot for your help, I'm sorry if I make you bored with my many questions, I hope they will decrease as soon as I will get acquainted with pypy's logic. ciao Anto
Antonio Cuni <anto.cuni@gmail.com> writes:
Hi, I'm writing the code that generates CLI classes starting from ootypesystem classes definitions, but as always I have a problem :-).
At the moment the only way to access class definitions is by calling TranslationContext.annotator.getuserclassdefinitions(), which returns a list of ClassDef instances: I've noticed that class attributes are not typed but only annotated.
Er. Well. I am almost entirely sure that your current approach of (simplified): for graph in self.translator.graphs: f = Function(graph) f.render(self.ilasm) is not really going to work. Have you looked at how (say) genc works? It first computes names for everything (the 'LowLevelDatabase'), and then spits out the code. 'everything' includes all the types referenced by the graphs, and because the graphs have been rtyped, the types you find are things like instances of ootype.Class.
Obviously for generating CLI classes I need to rtype class definitions, so that I can know the exact low-level type of the fields: I wondered if the absence of the rtyping step is intended or if it is a thing to do. In the latter case I could try to do it (hoping to do better than with rlist :-).
I'm not sure this question, as phrased, makes sense :) Cheers, mwh -- A witty saying proves nothing. -- Voltaire
Michael Hudson wrote:
Er. Well. I am almost entirely sure that your current approach of (simplified):
for graph in self.translator.graphs: f = Function(graph) f.render(self.ilasm)
is not really going to work. Have you looked at how (say) genc works? It first computes names for everything (the 'LowLevelDatabase'), and then spits out the code. 'everything' includes all the types referenced by the graphs, and because the graphs have been rtyped, the types you find are things like instances of ootype.Class.
Yes, I think you are probably right. It worked until now for simple experiments, but now I have to follow another approach, as I've just wrote to Niklaus. I hope to commit something usable tomorrow... ciao Anto
participants (3)
-
Antonio Cuni -
Michael Hudson -
Niklaus Haldimann