>  It seems to me that this should be part of Compiler class>>recompileAll, not just ReleaseBuilder. 

+1

>  I intend to keep it simple :-)

+1 :-)

> One question for the group; does each post compile hook method belong in the package containing its class or in e.g. the Compiler package?  My instinct is for the former.

Yes, the former because of package dependencies. It's like Shout's #aboutToStyle:(forMorph:) hook, which is also not implemented as extensions from the Shout package.

Best,
Marcel
Am 08.10.2019 18:59:03 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
Hi Levente, Hi All,

On Mon, Oct 7, 2019 at 2:44 PM Levente Uzonyi <leves at caesar.elte.hu [mailto:leves at caesar.elte.hu]> wrote:

On Mon, 7 Oct 2019, Eliot Miranda wrote:

> Hi All,
>     when I try and drive ReleaseBuilder programmatically I get a number of errors such as this:
>
> Error: Missing snapshot: Traits-pre.307
>
> It would be nice either to ignore such errors or to have an entry-point in ReleaseBuilder that just does the preference setting, recompileAll, condenseChanges and save.
>
>
> BTW, ReleaseBuilder's recompileAll appears not to be working perfectly.  With the new bytecode set installed we still expect to see quick methods compiled using the default bytecode set (something I have to fix but isn't high
> priority).  But even ignoring quick methods there are lots of methods that remain in the old bytecode set:
>
> CompiledMethod allInstances size 67104
> (CompiledMethod allInstances select: [:m| m signFlag]) size 61154
> (CompiledMethod allInstances reject: [:m| m signFlag or: [m isQuick]]) size 1253

Is it possible that the lingering methods are held by running processes?
Or that the method are not installed in classes anymore, so recompilation
can't get rid of them?


It is possible, but most of these are references from blocks.  Here are the methods; they are methods not in Etoys (Etoys has its own compiler that has yet to be ported to respect the preferred bytecode set preference) and are not quick methods (quick methods as yet are always in the old bytecode set).

MCRepository class>>#browseClassRevisionsService
MCRepository class>>#browseMethodRevisionsService
MorphicAlarmQueue>>#migrate
PluggableDictionary class>>#integerDictionary
ProcessBrowser class>>#registerWellKnownProcess:label:allowStop:allowDebug:
ProcessBrowser class>>#registerWellKnownProcesses
ServiceAction class>>#id:text:button:description:action:
ServiceAction class>>#text:button:description:action:
ServiceCategory class>>#text:button:description:
ServiceShortcuts class>>#insertPrefShortcut:
VariableNode class>>#initialize
Vocabulary class>>#newPublicVocabulary
WeakRegistry>>#installFinalizer
WorldMenuProvider>>#closeTopWindow
WorldMenuProvider>>#createNewService
WorldMenuProvider>>#helpOnServices
WorldMenuProvider>>#nextWindow
WorldMenuProvider>>#preferencesBrowser
WorldMenuProvider>>#rebuildRegistry
WorldMenuProvider>>#servicesBrowser
WorldState>>#stepListSortBlock

To deal with most of these ReleaseBuilder and/or Compiler recompileAll needs to effect 

"ServiceRegistry build" to rebuild the world menu,
"World worldState convertStepList" for its sort block
"WeakRegistry allInstances do: #installFinalizer" to update their finalizer block
"VariableNode initialize" to update StdLiteral's equalBlock (or reimpleent to use a Symbol instead of a block)
"Vocabulary addStandardVocabulary: Vocabulary newPublicVocabulary" to rebuild the one ScreenedVocabulary instance in the system

It seems to me we can eliminate almost all of these lingering methods by providing a post-recompile hook in classes that is invoked post-compile to rebuild structures that reference blocks.  It seems to me that this should be part of Compiler class>>recompileAll, not just ReleaseBuilder.  Unless people disagree strongly I shall push such a scheme to trunk.

The hook could be elaborate; for example using a pragma to specify a priority so that post compile rebuild actions happen in a predetermined order.  But looking at the issues above I see no need to do this.  I intend to keep it simple :-)

As far as the PluggableDictionary instances, one (VariableNode's StdLiterals) can be fixed by using a Symbol instead of a block.  There are some other integerDictionaries that need to be reinitialized using thee hook.

One question for the group; does each post compile hook method belong in the package containing its class or in e.g. the Compiler package?  My instinct is for the former.

Make sense?  Arguments against?


Levente

>
> But this could b e operator error.  I found the above while using a modified script that avoided checkForDirtyPackages.
> _,,,^..^,,,_
> best, Eliot
>
>



--

_,,,^..^,,,_

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191009/c71577c3/attachment.html>