On Tue, Dec 15, 2009 at 12:55 PM, Michael van der Gulik
<mikevdg at gmail.com>wrote:

> 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?
>

1.  When one redefines a method in the browser existing activations of the
old method are still potentially visible in the debugger.  If you try e.g.

Object methods for recompilation
haltInRecompile
    (self class whichClassIncludesSelector: thisContext messageSelector)
recompile: thisContext messageSelector.
    self halt

the halt will occur in the old version of haltInRecompile.  The Debugger may
show the method as e.g. Object>>unboundMethod.

2. if a package system supports overrides it is conceivable that the
overridden versions of methods are kept around in the event that unloading a
package will remove the overrides and need to reinstall the overridden ones.
At least that's what we did in VisualWorks.

3.  if the system supports breakpoints in methods it is conceivable that an
unbreak-pointed version of the method is squirrelled away while the
break-pointed version (which may contain a hidden send of halt or breakpoint
or whatever) is installed in its place.  At least that's what Terry
Raymond's Professional Debug package does for VisualWorks.

There may be other examples (John Brandt's MethodWrappers?).

All of the above examples are undermined by the fact that
condenseSources/condenseChanges et al works by enumerating over the class
hierarchy, looking only at installed methods.  So condense the changes and
you'll screw up the source for these hidden versions.  IMO the right
approach is to provide some registry for hidden methods, or at least a
visitor for methods in various hiding places, and have the source condensing
code enumerate over hidden methods in addition to the installed methods.

IMO, it is also important to search for senders in more than the installed
set.  It is useful to be able to search for them in hidden methods, but more
interestingly to be able to search for senders in class definitions, and in
package preamble and postamble scripts (and in VisualWorks, where namespace
global variables can have initializers, in global variable initializers).
 Abstracting away code searching from the class hierarchy is IMO a good
thing.  The class hierarchy is just one place to look, but others (such as
the above) will crop up.  Further, abstracting away what list browsers
operate on is a good idea.  Instead of just MethodReference one can also
have ClassReference (which displays the definition of a class)
PreambleReference (which displays a preamble, the "class" being the name of
the package.  So now one can search and browse for senders in odd places.
 Of course editing the definitions once you get there may not be possible,
but a helpful "open Monticello and edit the preamble for foo package
there-in" is perfectly acceptable (IMO).



> Gulik.
>
>
>
> --
> http://gulik.pbwiki.com/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091215/5a7368b6/attachment.htm