ReleaseBuilder fails to complete because of missing packages in checkForDirtyPackages

Am 08.10.2019 18:59:03 schrieb Eliot Miranda <[hidden email]>:

Hi Levente, Hi All,

On Mon, Oct 7, 2019 at 2:44 PM Levente Uzonyi <[hidden email]> 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

Am 07.10.2019 21:57:28 schrieb Eliot Miranda <[hidden email]>:

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

But this could b e operator error.  I found the above while using a modified script that avoided checkForDirtyPackages.

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

best, Eliot