Re: Question on browseUnimplemented

"Tim M" <365nice@xxxxxxxxx> wrote in message news:b88433471e088c89fdbd65c7a56@xxxxxxxxxxxxxxxxxxxxxxxx
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

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



.

Quantcast