[7.5] Unloadable definition issues

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[7.5] Unloadable definition issues

Randy Coulman
I just ran across an odd problem.  I was loading Michael's latest version of SmallSpotlight (74) and got an unloadable definition error for the override in VisualPart.  It wouldn't tell me why it was unloadable, so I tried to explicitly load it from the Unloadable Definitions window.  I got an error:

Store.UnloadableDefinitionError #dnu: #comment:

The root cause seems to be in Store.ClassRecord>>loadSrcInto:.  The call to #loadDefinition:into:logged: can return a UnloadableDefinitionError which then gets past the two guards in the next statement and gets passed to #loadCommentFor:.

After talking with Michael, I tried to do Definition | Remove from Package and got an error: "The identifier Visu has no binding".  This seems to be caused by PackageModel>>removeDefinitionFullClassSymbol: being called with #VisualPart.  That method calls String>>classNameOnly which assumes that "the receiver holds the metaclass name" and so strips off the last 6 characters of the class name. 

Randy
--
Randy Coulman
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [7.5] Unloadable definition issues

Alan Knight-2
I can't reproduce the particular problem with the SmallSpotlight 74 version in a clean 7.5 image from the public Store. However, the description is pretty clear, and the problem with dNU: #comment has come up before. I think we did fix it for the nil case, which happens for certain classes of errors, but not apparently for this other scenario. I've created AR 52923 for that and for the Remove From Package error.

As a workaround, you can babysit the code through in the debugger by telling it to return something from the loadCommentFor: method. It doesn't matter what, since the return value is not used.

At 02:08 PM 9/18/2007, Randy Coulman wrote:
I just ran across an odd problem.  I was loading Michael's latest version of SmallSpotlight (74) and got an unloadable definition error for the override in VisualPart.  It wouldn't tell me why it was unloadable, so I tried to explicitly load it from the Unloadable Definitions window.  I got an error:

Store.UnloadableDefinitionError #dnu: #comment:

The root cause seems to be in Store.ClassRecord>>loadSrcInto:.  The call to #loadDefinition:into:logged: can return a UnloadableDefinitionError which then gets past the two guards in the next statement and gets passed to #loadCommentFor:.

After talking with Michael, I tried to do Definition | Remove from Package and got an error: "The identifier Visu has no binding".  This seems to be caused by PackageModel>>removeDefinitionFullClassSymbol: being called with #VisualPart.  That method calls String>>classNameOnly which assumes that "the receiver holds the metaclass name" and so strips off the last 6 characters of the class name. 

Randy
--
Randy Coulman
[hidden email]

--
Alan Knight [|], Cincom Smalltalk Development
Reply | Threaded
Open this post in threaded view
|

Re: [7.5] Unloadable definition issues

Randy Coulman

On 9/18/07, Alan Knight <[hidden email]> wrote:
I can't reproduce the particular problem with the SmallSpotlight 74 version in a clean 7.5 image from the public Store. However, the description is pretty clear, and the problem with dNU: #comment has come up before. I think we did fix it for the nil case, which happens for certain classes of errors, but not apparently for this other scenario. I've created AR 52923 for that and for the Remove From Package error.

The particular problem was that the addition of a subscriptionRegistry instvar to VisualPart conflicted with a subclass of VisualPart in our code which already had the same instvar.  I published version 75 of SmallSpotlight to get around this after talking with Michael, so I'm not worried about that issue.

I just wanted to report the other bugs I found while working through this.

Thanks for the quick reply,
Randy
--
Randy Coulman
[hidden email]