<br><br><div class="gmail_quote">On Tue, Dec 15, 2009 at 12:55 PM, Michael van der Gulik <span dir="ltr">&lt;<a href="mailto:mikevdg@gmail.com">mikevdg@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Tue, Dec 15, 2009 at 9:16 PM, Nicolas Cellier<br>
&lt;<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>&gt; wrote:<br>
&gt; 2009/12/15 Michael van der Gulik &lt;<a href="mailto:mikevdg@gmail.com">mikevdg@gmail.com</a>&gt;:<br>
&gt;&gt; On Sun, Dec 13, 2009 at 4:17 AM, Igor Stasenko &lt;<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt; Here is my proposal for changing the method trailer in order to be<br>
&gt;&gt;&gt; able to encode various stuff to trailer.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Any corrections, suggestions are welcome.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The kind of compiled method trailer is determined by the last byte of<br>
&gt;&gt;&gt; compiled method.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The format is following:<br>
&gt;&gt;&gt;        &quot;2rkkkkkkdd&quot;<br>
&gt;&gt;<br>
&gt;&gt; Er... yuck.<br>
&gt;&gt;<br>
&gt;&gt; If I were doing this (which, cooincidently, I am at the moment), I<br>
&gt;&gt; would completely separate source code management from CompiledMethod.<br>
&gt;&gt;<br>
&gt;&gt; Trash the CompiledMethod trailer and ignore the temp names. Instead,<br>
&gt;&gt; add a second dictionary to Class which stores the source code pointers<br>
&gt;&gt; (&quot;sourceDictionary&quot; or something). If you don&#39;t want source code for a<br>
&gt;&gt; class, you can make it nil.<br>
&gt;&gt;<br>
&gt;&gt; What I&#39;m currently working on is a bit more radical. I&#39;m completely<br>
&gt;&gt; separating source code from it&#39;s compiled form. I have PackageSource,<br>
&gt;&gt; NamespaceSource, ClassSource and MethodSource classes which store<br>
&gt;&gt; source code (in the image, not using source files) and contain methods<br>
&gt;&gt; for compiling code, managing code, etc. Then I have Package,<br>
&gt;&gt; Namespace, Class and CompiledMethod classes which only contain what is<br>
&gt;&gt; necessary to run the code and relink themselves into a new image.<br>
&gt;&gt;<br>
&gt;&gt; Gulik.<br>
&gt;&gt;<br>
&gt;<br>
&gt; It is not uncommon to have some CompiledMethod not installed in any<br>
&gt; methodDictionary.<br>
&gt;     CompiledMethod allInstances reject: [:e | e isInstalled]<br>
&gt; Accessing associated source would become impossible in this scheme<br>
<br>
</div></div>Where would these exist? How would they be used?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Object methods for recompilation</div><div>haltInRecompile</div><div>    (self class whichClassIncludesSelector: thisContext messageSelector) recompile: thisContext messageSelector.</div><div>    self halt</div>
<div><br></div><div>the halt will occur in the old version of haltInRecompile.  The Debugger may show the method as e.g. Object&gt;&gt;unboundMethod.</div><div><br></div><div>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&#39;s what we did in VisualWorks.</div>
<div><br></div><div>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&#39;s what Terry Raymond&#39;s Professional Debug package does for VisualWorks.</div>
<div><br></div><div>There may be other examples (John Brandt&#39;s MethodWrappers?).</div><div><br></div><div>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&#39;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.</div>
<div><br></div><div>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 &quot;class&quot; 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 &quot;open Monticello and edit the preamble for foo package there-in&quot; is perfectly acceptable (IMO).</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
Gulik.<br>
<br>
<br>
<br>
--<br>
<a href="http://gulik.pbwiki.com/" target="_blank">http://gulik.pbwiki.com/</a><br>
<br>
</div></div></blockquote></div><br>