On Tue, Dec 15, 2009 at 9:16 PM, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 2009/12/15 Michael van der Gulik <mikevdg at gmail.com>:
>> On Sun, Dec 13, 2009 at 4:17 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>>> Here is my proposal for changing the method trailer in order to be
>>> able to encode various stuff to trailer.
>>>
>>> Any corrections, suggestions are welcome.
>>>
>>> The kind of compiled method trailer is determined by the last byte of
>>> compiled method.
>>>
>>> The format is following:
>>>        "2rkkkkkkdd"
>>
>> Er... yuck.
>>
>> If I were doing this (which, cooincidently, I am at the moment), I
>> would completely separate source code management from CompiledMethod.
>>
>> Trash the CompiledMethod trailer and ignore the temp names. Instead,
>> add a second dictionary to Class which stores the source code pointers
>> ("sourceDictionary" or something). If you don't want source code for a
>> class, you can make it nil.
>>
>> What I'm currently working on is a bit more radical. I'm completely
>> separating source code from it's compiled form. I have PackageSource,
>> NamespaceSource, ClassSource and MethodSource classes which store
>> source code (in the image, not using source files) and contain methods
>> for compiling code, managing code, etc. Then I have Package,
>> Namespace, Class and CompiledMethod classes which only contain what is
>> necessary to run the code and relink themselves into a new image.
>>
>> Gulik.
>>
>
> It is not uncommon to have some CompiledMethod not installed in any
> methodDictionary.
>     CompiledMethod allInstances reject: [:e | e isInstalled]
> Accessing associated source would become impossible in this scheme

Where would these exist? How would they be used?

Gulik.



-- 
http://gulik.pbwiki.com/