Question on browseUnimplemented

Dear OA - now you've opened the flood gates as I'm now a browseUnimplemented
junkie ;-)

I am noticing some errors which don't appear valid and so I want to check
I am using the output correctly.

e.g. I selected the latest port of Swazoo (in my dev image - not the exe
browser), selected the Swazoo package (which is last in the pre-req chain
of applications) - and I ran a #browseUnimplemented as described.

I get a browser with potential problems - many of them I can see are immediately
wrong, and some are of the form: x respondsTo: #someUndefinedSymbol which
I also understand.

However, I can see some like the following:

MessageBox>>basicOpen
        "Private - Display the receiver, and answer the Win32 Id of the button pressed
by the user."

        self assert: [self defaultButton <= self buttonIds size].
        self hasOwner ifTrue: [self owner ensureVisible].
        self isSuppressible ifTrue: [self showSuppressible] ifFalse: [self showIndirect].
        ^button

Where it claims References to #ensureVisible in Swazoo-Platform-Dolphin,
Dolphin, Dolphin Sockets, Swazoo-Platform, Smalltalk-Dialect, Dolphin Base64,
Swazoo

 From what I can see this is one of your methods, and from my understanding
of the UI stuff, self owner would be a view and it does impolement ensureVisible?
So what is this error telling me? Is it some missing prerequsitie - but then
this is a method in your Dolphin package so the pre-reqs can't be wrong?

A more direct example is in:

Package>>loadLegacyResources  it complains about #generateFilenameFrom:inPackage:
which is implemented again in your stuff.

How do I interprit these messages?

Tim

"Tim M" <[hidden email]> wrote in message
news:[hidden email]...
Tim

Are you running these against the "manifest" created for a deployed
application? I guess, so in which case the reports are correct. Those really
are potentially missing methods. Sometimes this happens when there is a
hidden dependency on a package that gets removed.

The MessageBox>>ensureVisible one is one such error - the Dolphin package
should not be sending #ensureVisible from MessageBox, because MessageBox is
in the base package, and #ensureVisible is only defined when 'Dolphin MVP
base is loaded'.

As it turns out this error is probably benign, since in order for
#ensureVisible to be sent to the owner View one must have been set, which
would be difficult to do without creating an identifiable dependency on the
MVP package. JNevertheless we'll fix this since MessageBox is not supposed
to have any MVP dependency.

The Package>>loadLegacyResources unimplemented message can be ignored.
Actually you shouldn't see this in a deployed application, but you will see
it if you use the "Browse Unimplemented" command in the package browser. The
Package system should be fully stripped from a deployed app, but obviously
it has to be part of the base system to facilitate the loading/unloading of
packages, so it is manually stripped, and thus gets included in the base
system when considering unimplemented messages based purely on the package
dependency graph. Package>>loadLegacyResources is on a code path that should
only ever be followed in the development system.

So there will be a core set you will always see. We do try to minimise
these, but sometime are just too expensive (in terms of time and complexity)
to eliminate. In a minimal deployed app such as the Console Hello World
there should only be one unimplemented message. Ideally there would be none.

To investigate whether or not an unimplemented message is a false positive,
you can use the MethodExplorer spawned from the ExecutableBrowser to track
down the references and see whether they are on a code path you expect to
get executed. The method explorer is constrained to see only that slice of
the image that will be in the deployed app, so it is a true representation
of the references that exist in that app. The Method Explorer that results
from using the package browser 'Unimplemented Messages' command is similarly
filtered, but shows a superset of what will actually be in the app, so is
less useful. Nevertheless it is useful for a quick check before starting
deployment.

Regards

OA

Hi Support,

> Are you running these against the "manifest" created for a deployed
> application? I guess, so in which case the reports are correct. Those
> really are potentially missing methods. Sometimes this happens when
> there is a hidden dependency on a package that gets removed.


Actually, I went back to my development image and ran the command against
a package browser (possibly my description wasn't clear enough) to route
out any issues before stripping adds further complexity. So I think s

>
> The MessageBox>>ensureVisible one is one such error - the Dolphin
> package should not be sending #ensureVisible from MessageBox, because
> MessageBox is in the base package, and #ensureVisible is only defined
> when 'Dolphin MVP base is loaded'.

Cool - my understanding is correct then

> The Package>>loadLegacyResources unimplemented message can be ignored.
> Actually you shouldn't see this in a deployed application, but you
> will see it if you use the "Browse Unimplemented" command in the
> package browser.

Ack - thats what I was doing - thanks for the more detailed explanation its
pretty clear to me now.

> So there will be a core set you will always see. We do try to minimise
> these, but sometime are just too expensive (in terms of time and
> complexity) to eliminate. In a minimal deployed app such as the
> Console Hello World there should only be one unimplemented message.
> Ideally there would be none.


So if I wanted to add a build test which checks for these unimplemented messages
in my stuff, chances are that I would need to miss out errors from Dolphin
system packages (which I can maintain a list of). It wouldn't be perfect
but as the goal is to automate and catch the real clangers - that just might
work?


> To investigate whether or not an unimplemented message is a false
> positive, you can use the MethodExplorer spawned from the
> ExecutableBrowser to track down the references and see whether they
> are on a code path you expect to get executed. The method explorer is
> constrained to see only that slice of the image that will be in the
> deployed app, so it is a true representation of the references that
> exist in that app.

Thats a nice tool - it certainly shows how Smalltalk environments have improved
from when I first used them (you were very much in the dark back then).

So thanks for the detailed reply - its been very educational. In summary,
I will see some things in the system packages that are false positives as
they are too expensive to truly fix, but on the whole I think I can use the
info to automate something.

Tim

"Tim M" <[hidden email]> wrote in message
news:[hidden email]...
>... So thanks for the detailed reply - its been very educational. In
>summary, I will see some things in the system packages that are false
>positives as they are too expensive to truly fix, but on the whole I think
>I can use the info to automate something.
>

If you are scripting the deployment, you could also make use of the
<UnimplementedMessages> section of the deployment XML log. The executable
browser doesn't use this (it calculates the unimplemented messages within
the "environment" against which it is configured, since it is capable of
wider use than just browsing the content of executables), but it might be
useful as part of a post deployment check. The messages it lists should be
actual message sends, rather than just symbolic references that have no
corresponding method.

Regards

OA