[7.7] ExternalInterface subclass definitions are wrong after load

I'm looking for a reason why my ExternalInterface subclasses appear to be mangled post-load from Store. As you can see in the attached, exactly the same bundle loaded in 7.6 and in 7.7 produces dramatically different results (bundle isn't marked as dirty post-load in 7.7 or anything like that; the load appears intact and does not produce any visible errors):

- library files are missing

- library directories are missing

- optimization level is debug instead of full

Any ideas?

Cheers,

-Boris

--

DeepCove Labs Ltd.

+1 (604) 689-0322

4th floor, 595 Howe Street

Vancouver, British Columbia

Canada V6C 2T5

http://tinyurl.com/r7uw4

PacNet Services (Europe) Ltd.

+353 (0)61 714-360

Shannon Airport House, SFZ

County Clare, Ireland

http://tinyurl.com/y952amr

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments.

Thank you.

Ha, and if I try to modify it in the browser to match 7.6 definition, I run into this error message "backup should be a LinkedOrderedCollection". The interesting bit is that clicking okay and attempting the exact same save again proceeds just fine and my interface once again functions as expected,

Error(GenericException)>>performHandler:

Error(GenericException)>>propagatePrivateFrom:

Error(GenericException)>>propagateFrom:

Error(GenericException)>>propagate

Error(GenericException)>>raiseSignal

Error class(GenericException class)>>raiseErrorString:

LinkedOrderedCollection(Object)>>error:

LinkedOrderedCollection>>addBackup:

DeepCoveLabs.CheckNSaveInterface class(ExternalInterface class)>>libraryDirectories:

DeepCoveLabs.CheckNSaveInterface class(ExternalInterface class)>>readExtraAttributes:oldSuperclass:

ClassBuilderRecord>>doExtraWork

optimized [] in [] in ClassBuilder>>reviseSystemSilently

Array(SequenceableCollection)>>do:

optimized [] in ClassBuilder>>reviseSystemSilently

BlockClosure>>on:do:

optimized [] in SystemUtils class>>modifySystem:

BlockClosure>>ensure:

SystemUtils class>>modifySystem:

ClassBuilder>>reviseSystemSilently

ClassBuilder>>reviseSystem

NameSpace>>defineClass:superclass:indexedType:private:instanceVariableNames:classInstanceVariableNames:imports:category:attributes:

UndefinedObject>>unboundMethod

UndefinedObject(Object)>>performMethod:arguments:

UndefinedObject(Object)>>performMethod:

Compiler(SmalltalkCompiler)>>evaluate:in:allowReceiver:receiver:environment:notifying:ifFail:

I'm looking for a reason why my ExternalInterface subclasses appear to be mangled post-load from Store. As you can see in the attached, exactly the same bundle loaded in 7.6 and in 7.7 produces dramatically different results (bundle isn't marked as dirty post-load in 7.7 or anything like that; the load appears intact and does not produce any visible errors):

- library files are missing

- library directories are missing

- optimization level is debug instead of full

Any ideas?

Cheers,

-Boris

--

DeepCove Labs Ltd.

+1 (604) 689-0322

4th floor, 595 Howe Street

Vancouver, British Columbia

Canada V6C 2T5

http://tinyurl.com/r7uw4

PacNet Services (Europe) Ltd.

+353 (0)61 714-360

Shannon Airport House, SFZ

County Clare, Ireland

http://tinyurl.com/y952amr

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments.

Thank you.

Just a quick update for anyone interested, it appears that load/install order was to blame, although it's not clear to me how exactly. I managed to load all subclasses of SmartExternalInterface cleanly as follows,

Before:

Top Bundle

 - Level 2 Bundle (DLLCC pre-requisite)

  - Level 3 Bundle A

   - Level 4 Package X (DeepCoveLabs namespace)

  - Level 3 Bundle B

   - Level 4 Package Y (SmartExternalInterface)

   - Level 4 Package Z (CheckNSaveInterface subclass of SmartExternalInterface)

After:

Top Bundle

 - Level 2 Bundle (DLLCC pre-requisite)

  - Level 3 Bundle A

   - Level 4 Package X (DeepCoveLabs namespace, SmartExternalInterface)

  - Level 3 Bundle B

   - Level 4 Package Z (CheckNSaveInterface subclass of SmartExternalInterface)

I didn't need to force installation of Level 4 Package X, by the way... Any ideas? I'm okay going forward, but it'd be interesting to know what could be causing this nonetheless.

Regards,

Yes, that's precisely what I'm suspicious of. That error message would come up in things like setting the directories and library files, and it does it using the superclass' variable. So if that hadn't got initialized properly, because of ordering issues with loading, or something else, then you might get that same error during load, but it gets suppressed, and the definition just doesn't get finished.

At 01:59 PM 2010-02-18, Boris Popov, DeepCove Labs \(YVR\) wrote:

Content-Class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary="----_=_NextPart_001_01CAB0CC.8E6F3029"

Thanks, Alan and Sames. I knew about the private change, it's the other bits that are wrong. In this case the superclass doesn't define anything at all of concern, just some helper methods, not DLLCC code, but I'll have a closer look again tomorrow. I wonder if the follow-up error I'm seeing is why these couldn't be defined properly, did you have a look at that as well?

-Boris (via BlackBerry)

From: Alan Knight <[hidden email]>
To: Samuel S. Shuster <[hidden email]>; Boris Popov, DeepCove Labs (YVR)
Cc: [hidden email] <[hidden email]>
Sent: Thu Feb 18 10:42:56 2010
Subject: Re: [vwnc] [7.7] ExternalInterface subclass definitions are wrong after load

In general, this looks to me like it might be mishandling of an error condition, possibly associated with the superclass, rather than the one that's showing the problem. If something went wrong and was silently handled and ignored, that would explain why definitions bits were missing, and why a variable might not have gotten initialized properly.

The bit about private import being different sounds like something that was fixed in 7.7. It used to be that you would get that gratuitously changing when publishing. It should be consistent now, but it's possible the first time you brought it in it might be different.

At 01:32 PM 2010-02-18, Samuel S. Shuster wrote:

Boris:

> I'm looking for a reason why my ExternalInterface subclasses appear to be mangled post-load from Store. As you can see in the attached, exactly the same bundle loaded in 7.6 and in 7.7 produces dramatically different results (bundle isn't marked as dirty post-load in 7.7 or anything like that; the load appears intact and does not produce any visible errors):
> 
> - library files are missing
> - library directories are missing
> - optimization level is debug instead of full
> 
> Any ideas?

Well, Alan and I have been putting our heads together this afternoon and came up with three possibilities:

1) The superclass (SmartExternalInterface) is IN the system when trying to load CheckNSaveInterface, and IT is initialized improperly.

2) The superclass (SmartExternalInterface) in the same package as CheckNSaveInterface, but it has some of its own implementation of some ExternalInterface method(s), and when compiling in  shadow land, it tries to execute this shadow code and all things fall apart from there.

3) The superclass (SmartExternalInterface) does something weird that breaks in 7.7

If the problem is #2, then the answer is to put the superclass in its own package, have it load BEFORE "this" package, and add a property on the package now holding SmartExternalInterface named #installBeforeContinuing... This will force the package to be installed alive in the system BEFORE loading the subclass.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?





_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc