Hi
I would like to know - when the annotations of lukas will be pushed in 3.9 - adrian would it be possible to fix the trait problem I would like to go beta soon. And only integrate the stuff of smallland. Marcus could you send me your list of pending items so that I can go over them. Stef |
On 05.02.2006, at 16:52, stéphane ducasse wrote: > Hi > > I would like to know > - when the annotations of lukas will be pushed in 3.9 I should have already done it. But I didn't. As soon as I find the energy and the time, I hope next week. > - adrian would it be possible to fix the trait problem > > I would like to go beta soon. > And only integrate the stuff of smallland. > > Marcus could you send me your list of pending items so that I can > go over them. I will have a look. Marcus |
> > I would like to know
> > - when the annotations of lukas will be pushed in 3.9 > > I should have already done it. But I didn't. As soon as I find the > energy and the time, I hope next week. I could provide a final and last change-set (this would be the 3rd attempt then), if we can finally decide on the design. After a lot of dicussion with Andreas and Marcus I would suggest the following implementation: - Every compiled method references an instance of MethodAnnotation, a class providing a place for instance-variables that should have been put into CompiledMethod if this was possible. - MethodAnnotation has got an inst-var called pragmas, that holds a collection of Pragmas that are added by the compiler at compile-time from constructs like <foo>, <foo: 1>, <foo: 1 bar: 2>, etc and that can be also reprinted to source when decompiling the CompiledMethod. - MethodAnnotation has got an inst-var called properties, that is initialized to nil but that might hold an identity-dictionary where any kind of properties can be stored (or cached), such as source, parse-tree, author initials, etc. The properties do not correspond to something in the source-code and therefor do not require a change to the parser/compiler/decompiler. Maybe this var could also be left-out and we ask people to add i-vars consuming much less memory. What do you think? Can everybody be happy with that? Should I now do it the last time? Lukas -- Lukas Renggli http://www.lukas-renggli.ch |
> What do you think? Can everybody be happy with that?
The definition class (fast #who) would be put where? Philippe |
> The definition class (fast #who) would be put where?
The definition class is already within the last literal of every-compiled method, this was already the case for all methods calling super but is now true for all the methods within the image. To answer your question: Other properties such as the selector of the method, source-code, last modification date could be put into an i-var/property of the MethodAnnotation object, since values like that do not have a representation in the source-code. Lukas -- Lukas Renggli http://www.lukas-renggli.ch |
In reply to this post by Lukas Renggli
if this solution is
compatible with VW and let tweak working Then this is good When I read the email of andreas about the size (in german) and read your reply it seems to me that this is ok. May be we could send an email in the mailing-list (but this will slow down the process) to get feedback? Stef On 5 févr. 06, at 19:42, Lukas Renggli wrote: >>> I would like to know >>> - when the annotations of lukas will be pushed in 3.9 >> >> I should have already done it. But I didn't. As soon as I find the >> energy and the time, I hope next week. > > I could provide a final and last change-set (this would be the 3rd > attempt then), if we can finally decide on the design. After a lot of > dicussion with Andreas and Marcus I would suggest the following > implementation: > > - Every compiled method references an instance of MethodAnnotation, a > class providing a place for instance-variables that should have been > put into CompiledMethod if this was possible. > > - MethodAnnotation has got an inst-var called pragmas, that holds a > collection of Pragmas that are added by the compiler at compile-time > from constructs like <foo>, <foo: 1>, <foo: 1 bar: 2>, etc and that > can be also reprinted to source when decompiling the CompiledMethod. > > - MethodAnnotation has got an inst-var called properties, that is > initialized to nil but that might hold an identity-dictionary where > any kind of properties can be stored (or cached), such as source, > parse-tree, author initials, etc. The properties do not correspond to > something in the source-code and therefor do not require a change to > the parser/compiler/decompiler. Maybe this var could also be left-out > and we ask people to add i-vars consuming much less memory. > > What do you think? Can everybody be happy with that? > > Should I now do it the last time? > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > |
In reply to this post by Lukas Renggli
On 05.02.2006, at 19:42, Lukas Renggli wrote: >>> I would like to know >>> - when the annotations of lukas will be pushed in 3.9 >> >> I should have already done it. But I didn't. As soon as I find the >> energy and the time, I hope next week. > > I could provide a final and last change-set (this would be the 3rd > attempt then), if we can finally decide on the design. After a lot of > dicussion with Andreas and Marcus I would suggest the following > implementation: > > - Every compiled method references an instance of MethodAnnotation, a > class providing a place for instance-variables that should have been > put into CompiledMethod if this was possible. > MethodExtension could be another name... don't really know if it is better, but it would community quite clearly that this is state that should be in the cm normally. > - MethodAnnotation has got an inst-var called pragmas, that holds a > collection of Pragmas that are added by the compiler at compile-time > from constructs like <foo>, <foo: 1>, <foo: 1 bar: 2>, etc and that > can be also reprinted to source when decompiling the CompiledMethod. > > - MethodAnnotation has got an inst-var called properties, that is > initialized to nil but that might hold an identity-dictionary where > any kind of properties can be stored (or cached), such as source, > parse-tree, author initials, etc. The properties do not correspond to > something in the source-code and therefor do not require a change to > the parser/compiler/decompiler. Maybe this var could also be left-out > and we ask people to add i-vars consuming much less memory. > I would like to have the properties... I guess mostly because adding an instvars as an extension is not possible with MC... So for experiments, it would be simpler. state that all instvars have (like selector) should definitly be in an instVar. > What do you think? Can everybody be happy with that? > Yes, sounds good. > Should I now do it the last time? > Yes, would be nice! Marcus |
Free forum by Nabble | Edit this page |